rebase

rebase

In D54218#1339119, @unitrunker_protonmail.com wrote:

usbconfig stopped reporting my webcam and fingerprint reader. Instead I get 'usbconfig: could not open device: Bad file descriptor'. Problem goes away when these changes are reverted. A very strange side note: libusb20_int.h is missing from base.txz for 15.1-RELEASE (but is in src.txz). I think the problem is I'm testing against 15.1-RELEASE which is too far behind current. I need to find some hardware onto which I can run current.

@markj would you mind eyeballing the mmap / pager stuff here? seuros is looking to refactor uvideo into a generic video layer and then drivers that implement this video API. Since uvideo got a bunch of pager/mmap related changes recently I'd like to make sure this gets done too.

hi @bapt ! so seuros here is neck deep in video/uvideo refactoring. Do you have any other uvideo stuff in the pipeline? I'd like to get the refactored video/uvideo split reviewed and in the tree before uvc lands and other bits/pieces for uvideo itself come in.

usbconfig stopped reporting my webcam and fingerprint reader. Instead I get 'usbconfig: could not open device: Bad file descriptor'. Problem goes away when these changes are reverted.
A very strange side note: libusb20_int.h is missing from base.txz for 15.1-RELEASE.

In D54296#1339098, @unitrunker_protonmail.com wrote:

usbconfig stopped reporting my webcam and fingerprint reader. Instead I get 'usbconfig: could not open device: Bad file descriptor'. Problem goes away when these changes are reverted.

usbconfig stopped reporting my webcam and fingerprint reader. Instead I get 'usbconfig: could not open device: Bad file descriptor'. Problem goes away when these changes are reverted.

@lwhsu @aokblast Ping

In D54218#1314423, @aokblast wrote:

Plus these point. Should we add O_CLOEXEC in here as libusb opened program can panic and thus flock never unlock

Good question. This device access model is simple - either the device is opened exclusively or shared. It never changes for the life of the device handle. If the process exits abruptly, I expect the host OS to clean up any open device and file handles. Once the handle is closed, the lock on the handle no longer applies.

Small fixes suggested by aokblast.

It is fine as-is, we can rename it later if needs be.

I tested this patch with two BUFFALO LUA2-TX (aue(4)) dongles that show the exact same dmesg.

@rkitover_gmail.com
Thank you for your effort.

I would like to understand the technical reasoning behind rejecting hidwacom before doing a rename. The rename itself is mechanical, but I want to understand what makes the name problematic so I can apply the same logic to future drivers.

In D56729#1300523, @guest-seuros wrote:

I think hidwacom is the better name here.

This is Wacom hardware, and it does not speak a generic "remote" protocol. It uses a Wacom-specific, undocumented HID report protocol. I decoded it from USB traffic captured against their Windows driver, and only later found that Linux already handles the same protocol in drivers/hid/wacom_wac.c under the hid-wacom driver.

If this were a published or vendor-neutral remote-control protocol, I would agree that hidremote would be a better name. But in this case, hidremote would make the driver look more generic than it really is.
The important part is not that the device is a remote, but that it is a Wacom HID device using Wacom-specific reports.

Linux also has support for multiple remotes and some additional quirks, but I cannot test those yet since I only have one ExpressKey Remote. I would rather land the tested base driver first and leave the untested multi-remote/quirk handling for future work.

Also, Wacom hardware is not limited to drawing tablets. Wacom EMR digitizers ship embedded in several laptops, including Lenovo ThinkPad X200t/X220t/X230t/Yoga models, and machines from HP, Dell, Asus, and Panasonic. Those are not drawing tablets either, but they still use Wacom-specific constants/protocol details. Samsung use it for their flagship phones and screens.

I will add the hidbus(4) xref.

Remove PHY checking, MII bus lock is sufficient

Hi, I have a patch for media in aue that should work, can you test please:

MII bus lock patch is here:

Add Differential Review to commit message

I've updated my patches to just use MII lock which is sufficient, as you found out, this one and:

Keep only MII bus lock, it's enough.

Keep only MII bus lock, it's enough.

Remove everything except MII bus lock, which is sufficient.

Also, thanks for you patient and contribution. This patch makes some improvement for multiple devices case.

Plus these point. Should we add O_CLOEXEC in here as libusb opened program can panic and thus flock never unlock