James Carlson wrote:
> Aaron Zang writes:
>> Aaron Zang wrote:
>>>> - How do these ioctls solve the problem? Who will issue the ioctls
>>>> and under what conditions? What happens if they're not used (if,
>>>> for example, something kills the Xorg server)?
>>>>
>>>>
>>> First, Xorg will open the hid devices upon startup. So the input goes
>>> to Xorg.
>>> While switching back to console, Xorg is in charge of issuing the
>>> ioctls to switch input
>>> to console since only Xorg has the context of which devices it keeps
>>> opening.
>>>
>>> If something kills the Xorg server, the opened files will be closed,
>>> so the input will
>>> automatically directed to the internal stream again.
>
> OK. I assume that Xorg can't just close the open file when switching
> to the console.
>
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.
>>> If we send the input to both the internal and external streams, when
>>> you are on console
>>> again no matter by switching back or Xorg exits, all the input
>>> characters typed under
>>> X will be shown on console, that would be messy.
>>>
>> Sorry, I was not 100% correct when trying to answer the latter question.
>> If all the input were sent to both the internal and external streams.
>> The upper conskbd
>> (virtual keyboard "/dev/kbd") would also get the input. If Xorg opens
>> /dev/kbd which
>> is the case for now, Xorg will get 2 copies of input.
>> If Xorg does not open "/dev/kbd", console will get the input and echo
>> back, that
>> would be the mess.
>
> OK. (I was just thinking about the mouse, but that makes sense for
> the keyboard.)
>
It may also make sense when someday console supports mouse (hopefuly :)
And I just thought if the process getting input from the console can
also get the input for the Xorg, it would be a security issue.
>> Actually we have already have a pair of similar ioctls (KIOC[GS]DIRECT])
>> to direct
>> the input in conskbd since conskbd also keeps 2 streams as you can see
>> from the
>> diagram in the case material.
>
> And those ioctls don't work because Xorg is now using /dev/usb/hid*,
> right? Even though it appears that the existing ioctls need to be
> dealt with down at the HID level ...
KIOC[GS]DIRECT would be never send down to the HID level. It is because
conskbd can not tell which keyboards are opened by Xorg and which are
not.
Say if there are 3 keyboards K1 K2 K3, and K1 and K2 are configure to be
opened by Xorg and K3 is left for console usage. Only K1 and K2 should
get the direct ioctl command while switching . But conskbd just can not
tell which one it should send the ioctls to.
>
> What happens if both KIOCSDIRECT and HIDIOCKMSDIRECT are used? Is it
> just "last to set?" What do you see if you do KIOCGDIRECT (get) after
> doing HIDIOCKMSDIRECT (set), if you set via KIOC* and get via HIDIOC*?
>
> (It's not clear to me who would ever need to 'get' this flag, but
> perhaps that's just a nit.)
>
As stated above, KIOCSDIRECT stops at conskbd level, it's function is
direct the 2 streams conskbd maintains. HIDIOCKMSDIRECT is for hid
keyboard/mouse devices and should be send down from /dev/usb/hid%d
directly, by passing conskbd/consms.
It is a 2x2 combination streams-vise.
"/dev/console" "/dev/kbd" "/dev/usb/hid%d"
"/dev/vt/%d" "/dev/mouse"
| | | Uesr Land
----------+---------+-----------+--------------
1-------------------> | | Kernel
+---------+ | |
| console | | |
+----+----+ | |
2-------> | | |
+----+---------+--+ |
| virtual keyboard| |
| mouse | |
+----------+------+ | <--- (HID external stream)
| |
3--------------> | |
+---------+ |
|
4-------------------------------> |
(HID internal stream) ---> | |
+--------+--+
| HID |
+-----------+
Regards,
Aaron
