HIDIOCKM[GS]DIRECT ioctls for the USB HID driver [PSARC/2009/329 FastTrack timeout 06/10/2009]

[Aaron Zang]

On 06/02/09 14:37, Darren Kenny wrote:
> On 01/06/2009 14:41, Aaron Zang wrote:

>>
>> Yes,  Xorg opens these files while with full privileges, for a normal
>> user login it will drop certain privileges, so it can not just close
>> the files and open again.
>>
> 
> So what happens if you plug in a new USB keyboard - if Xorg has dropped the
> privs, can it open that new device and do the ioctl?

No, if Xorg does not have enough privileges, it can not open the new
device, not to mention sending the ioctl. And maybe that's one of the reasons
that Xorg still opens /dev/kbd besides all the /dev/usb/hid%d.

> 
> I've recently noticed some similar errors in snv115 with Xorg and the use of HAL
> to inform it of new HID devices:
> 
> (II) config/hal: Adding input device keyboard
> (**) keyboard: always reports core events
> (**) Option "Device" "/dev/usb/hid0"
> (II) keyboard: Opened device "/dev/usb/hid0"
> (**) Option "StreamsModule" "usbkbm"
> (EE) keyboard: cannot push module 'usbkbm' onto keyboard device: Not owner
> (EE) keyboard: Unable to determine keyboard direct setting: Inappropriate ioctl
> for device
> (EE) PreInit failed for input device "keyboard"
> (II) UnloadModule: "kbd"
> (EE) config/hal: NewInputDeviceRequest failed
> 

I guess the keyboard is still usable under Xorg. It is because Xorg also
opens /dev/kbd. Whenever a new keyboard is plugged in, it will get plumbed
under conskbd, so even Xorg fails to open it directly via /dev/usb/hid%d,
it still can get the input via /dev/kbd.

That should be minor flaw of Xorg while using HAL.

Regards,
Aaron


-- 
You know some birds are not meant to be caged, their feathers are just too bright.
电脑这个玩意，你要是没有点好人品还真难成为高手。