From gd78059@sac.sfbay.sun.com Sun May 31 20:07:01 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n51371KT021470 for ; Sun, 31 May 2009 20:07:01 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n51371LX002705; Sun, 31 May 2009 20:07:01 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKJ00D01HZLYT00@brm-avmta-1.central.sun.com>; Sun, 31 May 2009 21:06:57 -0600 (MDT) Received: from dm-sfbay-01.sfbay.sun.com ([129.145.155.118]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKJ0074GHZLZ220@brm-avmta-1.central.sun.com>; Sun, 31 May 2009 21:06:57 -0600 (MDT) Received: from sac.sfbay.sun.com (sac.SFBay.Sun.COM [129.146.226.132]) by dm-sfbay-01.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n5136vrR011907; Sun, 31 May 2009 20:06:57 -0700 (PDT) Received: from sac.sfbay.sun.com (localhost [127.0.0.1]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5136tHn020937; Sun, 31 May 2009 20:06:55 -0700 (PDT) Received: (from gd78059@localhost) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8/Submit) id n5136t4E020923; Sun, 31 May 2009 20:06:55 -0700 (PDT) Date: Sun, 31 May 2009 20:06:55 -0700 (PDT) From: "Garrett D'Amore - sun microsystems" Subject: HIDIOCKM[GS]DIRECT ioctls for the USB HID driver [PSARC/2009/329 FastTrack timeout 06/10/2009] To: PSARC-ext@sun.com Cc: usb-tech@sun.com Message-id: <200906010306.n5136t4E020923@sac.sfbay.sun.com> Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 Status: RO Content-Length: 2067 Template Version: @(#)sac_nextcase 1.68 02/23/09 SMI This information is Copyright 2009 Sun Microsystems 1. Introduction 1.1. Project/Component Working Name: HIDIOCKM[GS]DIRECT ioctls for the USB HID driver 1.2. Name of Document Author/Supplier: Author: Aaron Zang 1.3 Date of This Document: 31 May, 2009 4. Technical Description HIDIOCKM[GS]DIRECT ioctls for the USB HID driver 1. Introduction 1.1 Project/Component Working Name: HIDIOCKM[GS]DIRECT ioctls for the USB HID driver 1.2 Name of Document Author/Supplier: Aaron Zang 1.3 Date of This Document: 05/25/09 2. Background The USB HID STREAMS driver exports 2 device nodes for each USB keyboard/mouse device instance. One is for the internal use of kernel under the name of "internal-keyboard" or "internal-mouse". The other is for the external use of user land applications under the name of "keyboard" or "mouse". If a keyboard/mouse device node is opened, a stream is established for the I/O of that node. The relationship of the internal node (stream), external node (stream), virtual keyboard mouse, console and applications are shown by the below diagram. "/dev/console" "/dev/kbd" "/dev/usb/hid%d" "/dev/vt/%d" "/dev/mouse" | | | Uesr Land ----------+---------+-----------+-------------- | | | Kernel +---------+ | | | console | | | +----+----+ | | | | | +----+---------+--+ | | virtual keyboard| | | mouse | | +----------+------+ | <--- (HID external stream) | | | | +---------+ | | | (HID interal stream) ---> | | +--------+--+ | HID | +-----------+ From the diagram we can see, the internal stream is used by console. Status: RO The external stream is used by applications which open the "/dev/usb/hid%d" device nodes directly. Since XOrg 1.5, the XOrg server opens hid deivces (/dev/usb/hid%d) by default instead of "/dev/kbd" or "/dev/mouse". Even before XOrg 1.5, it still can be configured to open the hid devices directly. 3. Problem When both of the internal and external node are opened, 2 streams are set up for both of them. But only one can get the the input from the hardware at one time. The internal stream usually gets the input first since the conskbd (virtual keyboard) driver opens the internal node when system boots. The current solution is that the input goes to the external stream when the external node is opened by some application, and the input gets switched back to the internal stream when the external stream was disassembled. When working on the XOrg support for Solaris Virtual Console, the project team found the console would lose input if switched back from one of the X sessions. It is because the XOrg server still opens the HID external node which causes the input still direct to the external stream. 4. Proposal To solve the above problem, two new HID ioctls are introduced: Exported Interface Stability Comments Name Classification ------------------ -------------- ---------- HIDIOCKMGDIRECT Committed See hid.7D HIDIOCKMSDIRECT Committed See hid.7D HIDIOCKMGDIRECT is used to get the information of which stream gets the input at the moment. A return value of 0 means the internal stream gets the input, and a return value of 1 means the external stream gets the input. HIDIOCKMSDIRECT is used to set the directing of the streams. An argument of 0 directs the input to the internal stream and an argument of 1 directs the input to the external stream. The existing behavior remains by the lasted opened stream gets the input automatically. 5. References PSARC/2006/591 Virtual Console PSARC/2004/717 Virtual Keyboard/Mouse hid(7D) 6. Resources and Schedule 6.4. Steering Committee requested information 6.4.1. Consolidation C-team Name: ON 6.5. ARC review type: FastTrack 6.6. ARC Exposure: open From gdamore@sun.com Sun May 31 20:18:39 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n513IcxA017198 for ; Sun, 31 May 2009 20:18:38 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n513ILi6024466; Mon, 1 Jun 2009 11:18:36 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKJ00F03IIX7F00@brm-avmta-1.central.sun.com>; Sun, 31 May 2009 21:18:33 -0600 (MDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKJ007HHIIWZ520@brm-avmta-1.central.sun.com>; Sun, 31 May 2009 21:18:32 -0600 (MDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n513IW6V025314; Sun, 31 May 2009 20:18:32 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KKJ00000I6KDO00@fe-sfbay-09.sun.com>; Sun, 31 May 2009 20:18:32 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KKJ00F7TIIVQRD0@fe-sfbay-09.sun.com>; Sun, 31 May 2009 20:18:32 -0700 (PDT) Date: Sun, 31 May 2009 20:18:31 -0700 From: "Garrett D'Amore" Subject: Re: HIDIOCKM[GS]DIRECT ioctls for the USB HID driver [PSARC/2009/329 FastTrack timeout 06/10/2009] In-reply-to: <200906010306.n5136t4E020923@sac.sfbay.sun.com> Sender: Garrett.Damore@sun.com To: "Garrett D'Amore - sun microsystems" Cc: PSARC-ext@sun.com, usb-tech@sun.com Message-id: <4A234887.9010908@sun.com> MIME-version: 1.0 Content-type: multipart/mixed; boundary="Boundary_(ID_4Gq6l6hQsKSv+EgSSxAgZQ)" X-PMX-Version: 5.4.1.325704 References: <200906010306.n5136t4E020923@sac.sfbay.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 7101 This is a multi-part message in MIME format. --Boundary_(ID_4Gq6l6hQsKSv+EgSSxAgZQ) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Here's an updated man page for hid.7d from Aaron: --Boundary_(ID_4Gq6l6hQsKSv+EgSSxAgZQ) Content-type: text/plain; name=hid.7d Content-transfer-encoding: 7BIT Content-disposition: inline; filename=hid.7d Devices hid(7D) NAME hid - Human interface device (HID) class driver SYNOPSIS keyboard@unit-address mouse@unit-address input@unit-address:consumer_control | #include | | int ioctl(int fildes, int command, ... /*arg*/); DESCRIPTION The hid driver is a USBA (Solaris USB Architecture) compli- ant client driver that supports the Human Interface Device Class (HID) 1.0 specification. The Human Interface Device (HID) class encompasses devices controlled by humans to operate computer systems. Typical examples of HID devices include keyboards, mice, trackballs, and joysticks. HID also covers front-panel controls such as knobs, switches, and buttons. A USB device with multiple interfaces may have one interface for audio and a HID interface to define the but- tons that control the audio. The hid driver is general and primarily handles the USB functionality of the device and generic HID functionality. For example, HID interfaces are required to have an inter- rupt pipe for the device to send data packets, and the hid driver opens the pipe to the interrupt endpoint and starts polling. The hid driver is also responsible for managing the device through the default control pipe. In addition to being a USB client driver, the hid driver is also a STREAMS driver so that modules may be pushed on top of it. The HID specification is flexible, and HID devices dynami- cally describe their packets and other parameters through a HID report descriptor. The HID parser is a misc module that parses the HID report descriptor and creates a database of information about the device. The hid driver queries the HID parser to find out the type and characteristics of the HID device. The HID specification predefines packet formats for the boot protocol keyboard and mouse. |IOCTLS | | HIDIOCKMGDIRECT | | This ioctl should only be addressed to a USB keyboard or | mouse device. The hid driver maintains two streams for | each USB keyboard/mouse instance -- an internal one for | the use of the kernel and an external one for the use of | user applications. This ioctl returns the information of | which stream gets the input for the moment. | | Arg must point to a variable of int type. Upon return, | "0" means the internal stream gets the input, "1" means | the external stream gets the input. | | HIDIOCKMSDIRECT | | This ioctl should only be addressed to a USB keyboard or | mouse device. The hid driver maintains two streams for | each USB keyboard/mouse instance -- an internal one for | the use of the kernel and an external one for the use of | user applications. This ioctl sets which stream should | get the input for the moment. | | Arg must point to a variable of int type. The argument | "0" means the internal stream should get the input, "1" | means the external stream should get the input. | FILES /kernel/drv/hid 32-bit x86 ELF kernel hid module /kernel/drv/amd64/hid 64-bit x86 ELF kernel hid module SunOS 5.11 Last change: 2 Dec 2005 1 Devices hid(7D) /kernel/drv/sparcv9/hid 64-bit SPARC ELF kernel hid module /kernel/misc/hidparser 32-bit x86 ELF kernel hidparser module /kernel/misc/amd64/hidparser 64-bit x86 ELF kernel hidparser module /kernel/misc/sparcv9/hidparser 64-bit SPARC ELF kernel hidparser module ATTRIBUTES See attributes(5) for descriptions of the following attri- butes: _____________________________________________________________ | ATTRIBUTE TYPE | ATTRIBUTE VALUE | |_____________________________|______________________________| | Architecture | SPARC, x86, PCI-based systems| |_____________________________|______________________________| | Availability | SUNWusb | |_____________________________|______________________________| SEE ALSO cfgadm_usb(1M), attributes(5), usba(7D), virtualkm(7D) Writing Device Drivers STREAMS Programming Guide Universal Serial Bus Specification 1.0 and 1.1 Device Class Definition for Human Interface Devices (HID) 1.1 SunOS 5.11 Last change: 2 Dec 2005 2 Devices hid(7D) System Administration Guide: Basic Administration http://www.sun.com/io DIAGNOSTICS hid_attach: Unsupported HID device. The device requires a protocol not supported by the hid driver. Parsing of hid descriptor failed. The HID report descriptor cannot be parsed correctly. The device cannot be supported by the hid driver. Invalid report descriptor. The HID report descriptor is invalid. The device cannot be supported by the hid driver. The following messages may be logged into the system log. They are formatted in the following manner: ): message... hid_attach: Unsupported HID device. The device cannot be supported by this version of the HID driver. Parsing of HID descriptor failed. The device cannot be supported by this version of the HID driver. Invalid report descriptor. The device cannot be supported by this version of the HID driver. NOTES SunOS 5.11 Last change: 2 Dec 2005 3 Devices hid(7D) The hid driver currently supports only keyboard, mouse and audio HID control devices. Normally a mouse is not power managed and consquently, screen darkening can be undone with a mouse movement. If power management of the mouse is required, add the following line to hid.conf then reboot the system: hid-mouse-pm-enable; Modern mice that are power managed require a 'click' to wake up. Occasionally, this may cause unexpected results. SunOS 5.11 Last change: 2 Dec 2005 4 --Boundary_(ID_4Gq6l6hQsKSv+EgSSxAgZQ)-- From carlsonj@phorcys.east.sun.com Mon Jun 1 04:43:59 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n51Bhxv7007617 for ; Mon, 1 Jun 2009 04:43:59 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n51BhxuJ011949; Mon, 1 Jun 2009 04:43:59 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKK005015XBM700@nwk-avmta-1.sfbay.Sun.COM>; Mon, 01 Jun 2009 04:43:59 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKK000Q65XA2OA0@nwk-avmta-1.sfbay.Sun.COM>; Mon, 01 Jun 2009 04:43:59 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n51Bhv51041430; Mon, 01 Jun 2009 07:43:57 -0400 (EDT) Received: from phorcys.east.sun.com (phorcys.local [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n51BgoF5002294; Mon, 01 Jun 2009 07:42:50 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n51BgoWX002291; Mon, 01 Jun 2009 07:42:50 -0400 (EDT) Date: Mon, 01 Jun 2009 07:42:50 -0400 From: James Carlson Subject: Re: HIDIOCKM[GS]DIRECT ioctls for the USB HID driver [PSARC/2009/329 FastTrack timeout 06/10/2009] In-reply-to: <200906010306.n5136t4E020923@sac.sfbay.sun.com> To: "Garrett D'Amore - sun microsystems" Cc: PSARC-ext@sun.com, usb-tech@sun.com Message-id: <18979.48826.207639.142420@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200906010306.n5136t4E020923@sac.sfbay.sun.com> Status: RO Content-Length: 634 Garrett D'Amore - sun microsystems writes: > To solve the above problem, two new HID ioctls are introduced: Two questions: - 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)? - Why not just send copies of the input to all open streams? Wouldn't that be simpler? -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Aaron.Zang@sun.com Mon Jun 1 05:29:40 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n51CTdkQ008275 for ; Mon, 1 Jun 2009 05:29:39 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n51CTYHN003374; Mon, 1 Jun 2009 20:29:38 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKK0040181C5I00@brm-avmta-1.central.sun.com>; Mon, 01 Jun 2009 06:29:36 -0600 (MDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKK001WN81AU900@brm-avmta-1.central.sun.com>; Mon, 01 Jun 2009 06:29:35 -0600 (MDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n51CTXFZ016047; Mon, 01 Jun 2009 12:29:33 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KKK007007TZFD00@mail-apac.sun.com>; Mon, 01 Jun 2009 20:29:33 +0800 (SGT) Received: from [192.168.1.33] ([unknown] [123.118.29.254]) by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KKK00BRN814HVC0@mail-apac.sun.com>; Mon, 01 Jun 2009 20:29:33 +0800 (SGT) Date: Mon, 01 Jun 2009 20:29:29 +0800 From: Aaron Zang Subject: Re: HIDIOCKM[GS]DIRECT ioctls for the USB HID driver [PSARC/2009/329 FastTrack timeout 06/10/2009] In-reply-to: <18979.48826.207639.142420@gargle.gargle.HOWL> Sender: Aaron.Zang@sun.com To: James Carlson Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, usb-tech@sun.com Message-id: <4A23C9A9.2000101@Sun.COM> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_6fLQRA5ukEpih6kjV2TN/w)" X-PMX-Version: 5.4.1.325704 References: <200906010306.n5136t4E020923@sac.sfbay.sun.com> <18979.48826.207639.142420@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) Status: RO Content-Length: 3253 This is a multi-part message in MIME format. --Boundary_(ID_6fLQRA5ukEpih6kjV2TN/w) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Hi James, James Carlson wrote: > Garrett D'Amore - sun microsystems writes: > >> To solve the above problem, two new HID ioctls are introduced: >> > > Two questions: > > - 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. > - Why not just send copies of the input to all open streams? > Wouldn't that be simpler? > > 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. Hope it answers your questions. Regards, Aaron --Boundary_(ID_6fLQRA5ukEpih6kjV2TN/w) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Hi James,


James Carlson wrote: 
Garrett D'Amore - sun microsystems writes:
  
To solve the above problem, two new HID ioctls are introduced:
    

Two questions:

  - 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.

  - Why not just send copies of the input to all open streams?
    Wouldn't that be simpler?

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.

Hope it answers your questions.

Regards,
Aaron

--Boundary_(ID_6fLQRA5ukEpih6kjV2TN/w)-- From Aaron.Zang@sun.com Mon Jun 1 05:40:03 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n51Ce3cG008312 for ; Mon, 1 Jun 2009 05:40:03 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n51Ce2Xw014404; Mon, 1 Jun 2009 05:40:03 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKK00G038IQD100@nwk-avmta-1.sfbay.Sun.COM>; Mon, 01 Jun 2009 05:40:02 -0700 (PDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKK000US8IP2ZC0@nwk-avmta-1.sfbay.Sun.COM>; Mon, 01 Jun 2009 05:40:01 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n51Ce0Zi016390; Mon, 01 Jun 2009 12:40:00 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KKK00C0089G0H00@mail-apac.sun.com>; Mon, 01 Jun 2009 20:40:00 +0800 (SGT) Received: from [192.168.1.33] ([unknown] [123.118.29.254]) by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KKK00BZ68IMHVC0@mail-apac.sun.com>; Mon, 01 Jun 2009 20:40:00 +0800 (SGT) Date: Mon, 01 Jun 2009 20:39:59 +0800 From: Aaron Zang Subject: Re: HIDIOCKM[GS]DIRECT ioctls for the USB HID driver [PSARC/2009/329 FastTrack timeout 06/10/2009] In-reply-to: <4A23C9A9.2000101@Sun.COM> Sender: Aaron.Zang@sun.com To: James Carlson Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, usb-tech@sun.com Message-id: <4A23CC1F.3040604@Sun.COM> MIME-version: 1.0 Content-type: multipart/alternative; boundary="Boundary_(ID_6l3MphquGHfZ2oaiAuxzSg)" X-PMX-Version: 5.4.1.325704 References: <200906010306.n5136t4E020923@sac.sfbay.sun.com> <18979.48826.207639.142420@gargle.gargle.HOWL> <4A23C9A9.2000101@Sun.COM> User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) Status: RO Content-Length: 4705 This is a multi-part message in MIME format. --Boundary_(ID_6l3MphquGHfZ2oaiAuxzSg) Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT Aaron Zang wrote: > Hi James, > > > James Carlson wrote: >> Garrett D'Amore - sun microsystems writes: >> >>> To solve the above problem, two new HID ioctls are introduced: >>> >> >> Two questions: >> >> - 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. > >> - Why not just send copies of the input to all open streams? >> Wouldn't that be simpler? >> >> > > 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. 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. Regards, Aaron --Boundary_(ID_6l3MphquGHfZ2oaiAuxzSg) Content-type: text/html; CHARSET=US-ASCII Content-transfer-encoding: 7BIT Aaron Zang wrote:
Hi James,


James Carlson wrote: 
Garrett D'Amore - sun microsystems writes:
  
To solve the above problem, two new HID ioctls are introduced:
    

Two questions:

  - 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.

  - Why not just send copies of the input to all open streams?
    Wouldn't that be simpler?

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.

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.

Regards,
Aaron


--Boundary_(ID_6l3MphquGHfZ2oaiAuxzSg)-- From carlsonj@phorcys.east.sun.com Mon Jun 1 05:53:49 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n51CrmDb008400 for ; Mon, 1 Jun 2009 05:53:48 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n51CrhTT001091; Mon, 1 Jun 2009 13:53:47 +0100 (BST) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKK0060395LN800@brm-avmta-1.central.sun.com>; Mon, 01 Jun 2009 06:53:45 -0600 (MDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKK001ID95KU420@brm-avmta-1.central.sun.com>; Mon, 01 Jun 2009 06:53:44 -0600 (MDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n51CrggV043724; Mon, 01 Jun 2009 08:53:42 -0400 (EDT) Received: from phorcys.east.sun.com (phorcys.local [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n51CqZpS002645; Mon, 01 Jun 2009 08:52:35 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n51CqZIE002642; Mon, 01 Jun 2009 08:52:35 -0400 (EDT) Date: Mon, 01 Jun 2009 08:52:35 -0400 From: James Carlson Subject: Re: HIDIOCKM[GS]DIRECT ioctls for the USB HID driver [PSARC/2009/329 FastTrack timeout 06/10/2009] In-reply-to: <4A23CC1F.3040604@Sun.COM> To: Aaron Zang Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, usb-tech@sun.com Message-id: <18979.53011.847291.507810@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200906010306.n5136t4E020923@sac.sfbay.sun.com> <18979.48826.207639.142420@gargle.gargle.HOWL> <4A23C9A9.2000101@Sun.COM> <4A23CC1F.3040604@Sun.COM> Status: RO Content-Length: 2447 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. > > 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.) > 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 ... 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.) -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Aaron.Zang@sun.com Mon Jun 1 06:41:38 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n51DfbfP009195 for ; Mon, 1 Jun 2009 06:41:38 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n51DfZkg029983; Mon, 1 Jun 2009 14:41:37 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKK0044NBDCR600@nwk-avmta-1.sfbay.Sun.COM>; Mon, 01 Jun 2009 06:41:36 -0700 (PDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKK003ROBDA8000@nwk-avmta-1.sfbay.Sun.COM>; Mon, 01 Jun 2009 06:41:35 -0700 (PDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n51DfYRS018069; Mon, 01 Jun 2009 13:41:34 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KKK00C00B1DCA00@mail-apac.sun.com>; Mon, 01 Jun 2009 21:41:34 +0800 (SGT) Received: from [192.168.1.33] ([unknown] [123.118.29.254]) by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KKK00JTXBD5ALD0@mail-apac.sun.com>; Mon, 01 Jun 2009 21:41:34 +0800 (SGT) Date: Mon, 01 Jun 2009 21:41:30 +0800 From: Aaron Zang Subject: Re: HIDIOCKM[GS]DIRECT ioctls for the USB HID driver [PSARC/2009/329 FastTrack timeout 06/10/2009] In-reply-to: <18979.53011.847291.507810@gargle.gargle.HOWL> Sender: Aaron.Zang@sun.com To: James Carlson Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, usb-tech@sun.com Message-id: <4A23DA8A.70608@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200906010306.n5136t4E020923@sac.sfbay.sun.com> <18979.48826.207639.142420@gargle.gargle.HOWL> <4A23C9A9.2000101@Sun.COM> <4A23CC1F.3040604@Sun.COM> <18979.53011.847291.507810@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) Status: RO Content-Length: 4339 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 From carlsonj@phorcys.east.sun.com Mon Jun 1 06:49:01 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n51Dn1es009260 for ; Mon, 1 Jun 2009 06:49:01 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n51DmwxG061972; Mon, 1 Jun 2009 07:49:01 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKK00603BPN4000@nwk-avmta-1.sfbay.Sun.COM>; Mon, 01 Jun 2009 06:48:59 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKK0031RBPM8620@nwk-avmta-1.sfbay.Sun.COM>; Mon, 01 Jun 2009 06:48:59 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n51DmvGo036542; Mon, 01 Jun 2009 09:48:57 -0400 (EDT) Received: from phorcys.east.sun.com (phorcys.local [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n51DlouG004107; Mon, 01 Jun 2009 09:47:50 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n51Dlot4004104; Mon, 01 Jun 2009 09:47:50 -0400 (EDT) Date: Mon, 01 Jun 2009 09:47:50 -0400 From: James Carlson Subject: Re: HIDIOCKM[GS]DIRECT ioctls for the USB HID driver [PSARC/2009/329 FastTrack timeout 06/10/2009] In-reply-to: <4A23DA8A.70608@Sun.COM> To: Aaron Zang Cc: "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, usb-tech@sun.com Message-id: <18979.56326.575734.127883@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200906010306.n5136t4E020923@sac.sfbay.sun.com> <18979.48826.207639.142420@gargle.gargle.HOWL> <4A23C9A9.2000101@Sun.COM> <4A23CC1F.3040604@Sun.COM> <18979.53011.847291.507810@gargle.gargle.HOWL> <4A23DA8A.70608@Sun.COM> Status: RO Content-Length: 513 Aaron Zang writes: > 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. OK; got it now. +1 -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Darren.Kenny@sun.com Mon Jun 1 23:38:01 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n526c0Jd018882 for ; Mon, 1 Jun 2009 23:38:00 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n526c05W026768; Mon, 1 Jun 2009 23:38:00 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKL00H01MFB4700@nwk-avmta-1.sfbay.Sun.COM>; Mon, 01 Jun 2009 23:37:59 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKL008TZMF9K990@nwk-avmta-1.sfbay.Sun.COM>; Mon, 01 Jun 2009 23:37:58 -0700 (PDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n526bv0o011690; Tue, 02 Jun 2009 06:37:57 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KKL00600MERM600@fe-emea-10.sun.com>; Tue, 02 Jun 2009 07:37:57 +0100 (BST) Received: from [129.156.226.38] ([unknown] [129.156.226.38]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KKL00EVXMF9BZ30@fe-emea-10.sun.com>; Tue, 02 Jun 2009 07:37:57 +0100 (BST) Date: Tue, 02 Jun 2009 07:37:57 +0100 From: Darren Kenny Subject: Re: HIDIOCKM[GS]DIRECT ioctls for the USB HID driver [PSARC/2009/329 FastTrack timeout 06/10/2009] In-reply-to: <4A23DA8A.70608@Sun.COM> Sender: Darren.Kenny@sun.com To: Aaron Zang Cc: James Carlson , "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, usb-tech@sun.com Message-id: <4A24C8C5.3050903@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200906010306.n5136t4E020923@sac.sfbay.sun.com> <18979.48826.207639.142420@gargle.gargle.HOWL> <4A23C9A9.2000101@Sun.COM> <4A23CC1F.3040604@Sun.COM> <18979.53011.847291.507810@gargle.gargle.HOWL> <4A23DA8A.70608@Sun.COM> User-Agent: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.9.1b5pre) Gecko/20090513 Lightning/1.0pre Shredder/3.0b3pre ThunderBrowse/3.2.4 Status: RO Content-Length: 1804 On 01/06/2009 14:41, Aaron Zang wrote: > 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. > 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? 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 Thanks, Darren. From Aaron.Zang@sun.com Mon Jun 1 23:59:00 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n526x07G019338 for ; Mon, 1 Jun 2009 23:59:00 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n526wsDc009263; Mon, 1 Jun 2009 23:58:59 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKL0042PNE9N200@brm-avmta-1.central.sun.com>; Tue, 02 Jun 2009 00:58:57 -0600 (MDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKL00HXUNE89140@brm-avmta-1.central.sun.com>; Tue, 02 Jun 2009 00:58:56 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n526wtHh021671; Tue, 02 Jun 2009 06:58:55 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KKL00100MXVO700@fe-emea-10.sun.com>; Tue, 02 Jun 2009 07:58:55 +0100 (BST) Received: from [129.158.217.200] ([unknown] [129.158.217.200]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KKL00MF1NDRX3E0@fe-emea-10.sun.com>; Tue, 02 Jun 2009 07:58:44 +0100 (BST) Date: Tue, 02 Jun 2009 14:58:58 +0800 From: Aaron Zang Subject: Re: HIDIOCKM[GS]DIRECT ioctls for the USB HID driver [PSARC/2009/329 FastTrack timeout 06/10/2009] In-reply-to: <4A24C8C5.3050903@Sun.COM> Sender: Aaron.Zang@sun.com To: Darren Kenny Cc: James Carlson , "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, usb-tech@sun.com Message-id: <4A24CDB2.7070403@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <200906010306.n5136t4E020923@sac.sfbay.sun.com> <18979.48826.207639.142420@gargle.gargle.HOWL> <4A23C9A9.2000101@Sun.COM> <4A23CC1F.3040604@Sun.COM> <18979.53011.847291.507810@gargle.gargle.HOWL> <4A23DA8A.70608@Sun.COM> <4A24C8C5.3050903@Sun.COM> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 1746 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. 电脑这个玩意，你要是没有点好人品还真难成为高手。 From carlsonj@phorcys.east.sun.com Tue Jun 2 04:09:05 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n52B94PM021135 for ; Tue, 2 Jun 2009 04:09:04 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n52B8irh022338; Tue, 2 Jun 2009 19:09:03 +0800 (SGT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKL0070FYZ0F000@brm-avmta-1.central.sun.com>; Tue, 02 Jun 2009 05:09:00 -0600 (MDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKL00J7CYYZDB90@brm-avmta-1.central.sun.com>; Tue, 02 Jun 2009 05:09:00 -0600 (MDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n52B8vYk037965; Tue, 02 Jun 2009 07:08:57 -0400 (EDT) Received: from phorcys.east.sun.com (phorcys.local [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n52B7orx006502; Tue, 02 Jun 2009 07:07:50 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n52B7oRE006499; Tue, 02 Jun 2009 07:07:50 -0400 (EDT) Date: Tue, 02 Jun 2009 07:07:50 -0400 From: James Carlson Subject: Re: HIDIOCKM[GS]DIRECT ioctls for the USB HID driver [PSARC/2009/329 FastTrack timeout 06/10/2009] In-reply-to: <4A24CDB2.7070403@Sun.COM> To: Aaron Zang Cc: Darren Kenny , "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, usb-tech@sun.com Message-id: <18981.2054.360285.456981@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200906010306.n5136t4E020923@sac.sfbay.sun.com> <18979.48826.207639.142420@gargle.gargle.HOWL> <4A23C9A9.2000101@Sun.COM> <4A23CC1F.3040604@Sun.COM> <18979.53011.847291.507810@gargle.gargle.HOWL> <4A23DA8A.70608@Sun.COM> <4A24C8C5.3050903@Sun.COM> <4A24CDB2.7070403@Sun.COM> Status: RO Content-Length: 832 Aaron Zang writes: > 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. That's a bit confusing. If both /dev/kbd and /dev/usb/hid* work properly, but the latter relies privileges that are currently mishandled in Xorg, then why bother with the trouble of using those HID nodes at all? (At least there should be a CR filed on this.) -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Aaron.Zang@sun.com Tue Jun 2 06:00:08 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n52D07ct021962 for ; Tue, 2 Jun 2009 06:00:07 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n52D06at014603; Tue, 2 Jun 2009 06:00:07 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKM00J054463K00@brm-avmta-1.central.sun.com>; Tue, 02 Jun 2009 07:00:06 -0600 (MDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKM00G3M441BJ20@brm-avmta-1.central.sun.com>; Tue, 02 Jun 2009 07:00:02 -0600 (MDT) Received: from fe-apac-06.sun.com (fe-apac-06.sun.com [192.18.19.177] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n52D0092016483; Tue, 02 Jun 2009 13:00:01 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KKM00J003UAEZ00@mail-apac.sun.com>; Tue, 02 Jun 2009 21:00:00 +0800 (SGT) Received: from [192.168.1.33] ([unknown] [123.118.9.249]) by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KKM00LDR43W6Z50@mail-apac.sun.com>; Tue, 02 Jun 2009 21:00:00 +0800 (SGT) Date: Tue, 02 Jun 2009 20:59:58 +0800 From: Aaron Zang Subject: Re: HIDIOCKM[GS]DIRECT ioctls for the USB HID driver [PSARC/2009/329 FastTrack timeout 06/10/2009] In-reply-to: <18981.2054.360285.456981@gargle.gargle.HOWL> Sender: Aaron.Zang@sun.com To: James Carlson Cc: Darren Kenny , "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, usb-tech@sun.com Message-id: <4A25224E.1040005@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200906010306.n5136t4E020923@sac.sfbay.sun.com> <18979.48826.207639.142420@gargle.gargle.HOWL> <4A23C9A9.2000101@Sun.COM> <4A23CC1F.3040604@Sun.COM> <18979.53011.847291.507810@gargle.gargle.HOWL> <4A23DA8A.70608@Sun.COM> <4A24C8C5.3050903@Sun.COM> <4A24CDB2.7070403@Sun.COM> <18981.2054.360285.456981@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) Status: RO Content-Length: 1129 James Carlson wrote: > Aaron Zang writes: >> 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. > > That's a bit confusing. If both /dev/kbd and /dev/usb/hid* work > properly, but the latter relies privileges that are currently > mishandled in Xorg, then why bother with the trouble of using those > HID nodes at all? > It's a new feature of Xorg using the hid nodes. Because if Xorg only uses /dev/kbd, all keyboards function as the same. If Xorg use each hid nodes independently, it can configure each keyboard with different properties such as key mappings. There should be many other benefits besides that which prompted the Xorg community to adopt the hid nodes. > (At least there should be a CR filed on this.) > There should be, and I guess there must already have had one. I will check it, if otherwise I will file one. Regards, Aaron From carlsonj@phorcys.east.sun.com Tue Jun 2 06:04:33 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n52D4XNs022078 for ; Tue, 2 Jun 2009 06:04:33 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n52D4X7W017649; Tue, 2 Jun 2009 06:04:33 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKM00J054BLIT00@brm-avmta-1.central.sun.com>; Tue, 02 Jun 2009 07:04:33 -0600 (MDT) Received: from dm-east-01.east.sun.com ([129.148.9.192]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKM00GJV4BKBJ20@brm-avmta-1.central.sun.com>; Tue, 02 Jun 2009 07:04:33 -0600 (MDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-01.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n52D4Uhk056875; Tue, 02 Jun 2009 09:04:30 -0400 (EDT) Received: from phorcys.east.sun.com (phorcys.local [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n52D3NWL007132; Tue, 02 Jun 2009 09:03:23 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n52D3Nuq007129; Tue, 02 Jun 2009 09:03:23 -0400 (EDT) Date: Tue, 02 Jun 2009 09:03:23 -0400 From: James Carlson Subject: Re: HIDIOCKM[GS]DIRECT ioctls for the USB HID driver [PSARC/2009/329 FastTrack timeout 06/10/2009] In-reply-to: <4A25224E.1040005@Sun.COM> To: Aaron Zang Cc: Darren Kenny , "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, usb-tech@sun.com Message-id: <18981.8987.649158.544269@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200906010306.n5136t4E020923@sac.sfbay.sun.com> <18979.48826.207639.142420@gargle.gargle.HOWL> <4A23C9A9.2000101@Sun.COM> <4A23CC1F.3040604@Sun.COM> <18979.53011.847291.507810@gargle.gargle.HOWL> <4A23DA8A.70608@Sun.COM> <4A24C8C5.3050903@Sun.COM> <4A24CDB2.7070403@Sun.COM> <18981.2054.360285.456981@gargle.gargle.HOWL> <4A25224E.1040005@Sun.COM> Status: RO Content-Length: 424 Aaron Zang writes: > > (At least there should be a CR filed on this.) > > > > There should be, and I guess there must already have had one. > I will check it, if otherwise I will file one. Thanks. -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From alan.coopersmith@sun.com Tue Jun 2 14:35:44 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n52LZi5b001317 for ; Tue, 2 Jun 2009 14:35:44 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n52LZgWD063151; Tue, 2 Jun 2009 15:35:43 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKM00L03RZJKI00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 02 Jun 2009 14:35:43 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKM00BNFRZJK750@nwk-avmta-1.sfbay.Sun.COM>; Tue, 02 Jun 2009 14:35:43 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n52LZg7T005280; Tue, 02 Jun 2009 14:35:42 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KKM00500RT8IN00@fe-sfbay-09.sun.com>; Tue, 02 Jun 2009 14:35:42 -0700 (PDT) Received: from [10.6.102.27] ([unknown] [10.6.102.27]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KKM0077URZIA7F0@fe-sfbay-09.sun.com>; Tue, 02 Jun 2009 14:35:42 -0700 (PDT) Date: Tue, 02 Jun 2009 14:35:42 -0700 From: Alan Coopersmith Subject: Re: HIDIOCKM[GS]DIRECT ioctls for the USB HID driver [PSARC/2009/329 FastTrack timeout 06/10/2009] In-reply-to: <18979.53011.847291.507810@gargle.gargle.HOWL> Sender: alan.coopersmith@sun.com To: James Carlson Cc: Aaron Zang , "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, usb-tech@sun.com Message-id: <4A259B2E.5000905@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <200906010306.n5136t4E020923@sac.sfbay.sun.com> <18979.48826.207639.142420@gargle.gargle.HOWL> <4A23C9A9.2000101@Sun.COM> <4A23CC1F.3040604@Sun.COM> <18979.53011.847291.507810@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 356 James Carlson wrote: > OK. I assume that Xorg can't just close the open file when switching > to the console. We're opening and closing them on hotplug and suspend-resume, so I would think vt-switch would be able to handle them the same. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From Alan.Coopersmith@sun.com Tue Jun 2 14:38:12 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n52LcBha001335 for ; Tue, 2 Jun 2009 14:38:12 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n52Lc9FV014148; Tue, 2 Jun 2009 22:38:11 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKM00L1NS3LY100@nwk-avmta-2.sfbay.sun.com>; Tue, 02 Jun 2009 14:38:09 -0700 (PDT) Received: from sca-es-mail-1.sun.com ([192.18.43.132]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKM0090NS3LNPD0@nwk-avmta-2.sfbay.sun.com>; Tue, 02 Jun 2009 14:38:09 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n52Lc9Eq002037; Tue, 02 Jun 2009 14:38:09 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KKM00500RT8IN00@fe-sfbay-09.sun.com>; Tue, 02 Jun 2009 14:38:09 -0700 (PDT) Received: from [10.6.102.27] ([unknown] [10.6.102.27]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KKM007ZXS3KA7F0@fe-sfbay-09.sun.com>; Tue, 02 Jun 2009 14:38:09 -0700 (PDT) Date: Tue, 02 Jun 2009 14:38:08 -0700 From: Alan Coopersmith Subject: Re: HIDIOCKM[GS]DIRECT ioctls for the USB HID driver [PSARC/2009/329 FastTrack timeout 06/10/2009] In-reply-to: <4A24C8C5.3050903@Sun.COM> Sender: Alan.Coopersmith@sun.com To: Darren Kenny Cc: Aaron Zang , James Carlson , "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, usb-tech@sun.com Message-id: <4A259BC0.3040801@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <200906010306.n5136t4E020923@sac.sfbay.sun.com> <18979.48826.207639.142420@gargle.gargle.HOWL> <4A23C9A9.2000101@Sun.COM> <4A23CC1F.3040604@Sun.COM> <18979.53011.847291.507810@gargle.gargle.HOWL> <4A23DA8A.70608@Sun.COM> <4A24C8C5.3050903@Sun.COM> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 1087 Darren Kenny wrote: > 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? > > 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 That's a bug that was just reported to me in private e-mail while I was out on vacation last week. We need to fix Xorg to setuid back to root before opening hotplugged devices. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From carlsonj@phorcys.east.sun.com Tue Jun 2 17:01:47 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5301lqg003112 for ; Tue, 2 Jun 2009 17:01:47 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n5301MKX000168; Wed, 3 Jun 2009 01:01:46 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKM00807YQWLX00@nwk-avmta-2.sfbay.sun.com>; Tue, 02 Jun 2009 17:01:44 -0700 (PDT) Received: from dm-east-02.east.sun.com ([129.148.13.5]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKM005S2YQVGK10@nwk-avmta-2.sfbay.sun.com>; Tue, 02 Jun 2009 17:01:43 -0700 (PDT) Received: from phorcys.east.sun.com (phorcys.East.Sun.COM [129.148.174.143]) by dm-east-02.east.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n5301euP049645; Tue, 02 Jun 2009 20:01:40 -0400 (EDT) Received: from phorcys.east.sun.com (phorcys.local [127.0.0.1]) by phorcys.east.sun.com (8.14.3+Sun/8.14.3) with ESMTP id n5300X2C010287; Tue, 02 Jun 2009 20:00:33 -0400 (EDT) Received: (from carlsonj@localhost) by phorcys.east.sun.com (8.14.3+Sun/8.14.3/Submit) id n5300X6O010284; Tue, 02 Jun 2009 20:00:33 -0400 (EDT) Date: Tue, 02 Jun 2009 20:00:33 -0400 From: James Carlson Subject: Re: HIDIOCKM[GS]DIRECT ioctls for the USB HID driver [PSARC/2009/329 FastTrack timeout 06/10/2009] In-reply-to: <4A259BC0.3040801@sun.com> To: Alan Coopersmith Cc: Darren Kenny , Aaron Zang , "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, usb-tech@sun.com Message-id: <18981.48417.257124.786246@gargle.gargle.HOWL> MIME-version: 1.0 X-Mailer: VM 7.01 under Emacs 21.3.1 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <200906010306.n5136t4E020923@sac.sfbay.sun.com> <18979.48826.207639.142420@gargle.gargle.HOWL> <4A23C9A9.2000101@Sun.COM> <4A23CC1F.3040604@Sun.COM> <18979.53011.847291.507810@gargle.gargle.HOWL> <4A23DA8A.70608@Sun.COM> <4A24C8C5.3050903@Sun.COM> <4A259BC0.3040801@sun.com> Status: RO Content-Length: 586 Alan Coopersmith writes: > That's a bug that was just reported to me in private e-mail while I was out on > vacation last week. We need to fix Xorg to setuid back to root before opening > hotplugged devices. So ... with that bug fixed, does the need for this special ioctl remain? Doesn't closing the descriptor and reopening it when needed fix the problem? -- James Carlson, Solaris Networking Sun Microsystems / 35 Network Drive 71.232W Vox +1 781 442 2084 MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677 From Alan.Coopersmith@sun.com Tue Jun 2 17:28:23 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n530SMQY003224 for ; Tue, 2 Jun 2009 17:28:22 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n530SHwk010166; Wed, 3 Jun 2009 08:28:21 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKM00A05ZZ7DR00@nwk-avmta-2.sfbay.sun.com>; Tue, 02 Jun 2009 17:28:19 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKM005TOZZ7G820@nwk-avmta-2.sfbay.sun.com>; Tue, 02 Jun 2009 17:28:19 -0700 (PDT) Received: from fe-sfbay-09.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n530SI3l020444; Tue, 02 Jun 2009 17:28:18 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-09.sun.com by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KKM00B00ZPXQO00@fe-sfbay-09.sun.com>; Tue, 02 Jun 2009 17:28:18 -0700 (PDT) Received: from [10.6.102.27] ([unknown] [10.6.102.27]) by fe-sfbay-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KKM00DF1ZZ6RY00@fe-sfbay-09.sun.com>; Tue, 02 Jun 2009 17:28:18 -0700 (PDT) Date: Tue, 02 Jun 2009 17:28:18 -0700 From: Alan Coopersmith Subject: Re: HIDIOCKM[GS]DIRECT ioctls for the USB HID driver [PSARC/2009/329 FastTrack timeout 06/10/2009] In-reply-to: <18981.48417.257124.786246@gargle.gargle.HOWL> Sender: Alan.Coopersmith@sun.com To: James Carlson Cc: Darren Kenny , Aaron Zang , "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, usb-tech@sun.com Message-id: <4A25C3A2.9020800@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 X-Enigmail-Version: 0.95.1 References: <200906010306.n5136t4E020923@sac.sfbay.sun.com> <18979.48826.207639.142420@gargle.gargle.HOWL> <4A23C9A9.2000101@Sun.COM> <4A23CC1F.3040604@Sun.COM> <18979.53011.847291.507810@gargle.gargle.HOWL> <4A23DA8A.70608@Sun.COM> <4A24C8C5.3050903@Sun.COM> <4A259BC0.3040801@sun.com> <18981.48417.257124.786246@gargle.gargle.HOWL> User-Agent: Thunderbird 2.0.0.21 (X11/20090323) Status: RO Content-Length: 1457 James Carlson wrote: > Alan Coopersmith writes: >> That's a bug that was just reported to me in private e-mail while I was out on >> vacation last week. We need to fix Xorg to setuid back to root before opening >> hotplugged devices. > > So ... with that bug fixed, does the need for this special ioctl > remain? Doesn't closing the descriptor and reopening it when needed > fix the problem? Now that I've had a chance to look at it and not just read the e-mail, I'm trying to determine if that is the correct fix or if the bug is in the kernel side. The devices are owned by the uid Xorg is running as, due to logindevperms, but it seems additional privileges are being required by the kernel drivers (PRIV_SYS_DEVICES) - if it's correct for them to require that, then I'll work on fixing Xorg to seteuid(0) there. (Xorg has not been made privilege aware so far since the two states it has needed in the past are "all privileges" during server/device initialization, and the basic set provided by seteuid to a non-root user during most of runtime, so there was no benefit in adding privilege awareness to the code.) I was not involved in the decision to create this ioctl, so I can't answer their motivations or why the project team decided creating an ioctl was better than adding an additional spot for Xorg to return to uid 0. -- -Alan Coopersmith- alan.coopersmith@sun.com Sun Microsystems, Inc. - X Window System Engineering From Aaron.Zang@Sun.COM Tue Jun 2 17:45:53 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n530jqcZ003656 for ; Tue, 2 Jun 2009 17:45:53 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n530jpGU026899; Wed, 3 Jun 2009 01:45:52 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKN00E030SF1C00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 02 Jun 2009 17:45:51 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKN000130SE4E30@nwk-avmta-1.sfbay.Sun.COM>; Tue, 02 Jun 2009 17:45:51 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n530jnKd003911; Wed, 03 Jun 2009 00:45:49 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KKN000000O23900@fe-emea-09.sun.com>; Wed, 03 Jun 2009 01:45:49 +0100 (BST) Received: from [129.158.217.200] ([unknown] [129.158.217.200]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KKN0022E0S5XE60@fe-emea-09.sun.com>; Wed, 03 Jun 2009 01:45:49 +0100 (BST) Date: Wed, 03 Jun 2009 08:46:00 +0800 From: Aaron Zang Subject: Re: HIDIOCKM[GS]DIRECT ioctls for the USB HID driver [PSARC/2009/329 FastTrack timeout 06/10/2009] In-reply-to: <4A25C3A2.9020800@sun.com> Sender: Aaron.Zang@Sun.COM To: Alan Coopersmith Cc: James Carlson , Darren Kenny , "Garrett D'Amore - sun microsystems" , PSARC-ext@Sun.COM, usb-tech@Sun.COM Message-id: <4A25C7C8.5010400@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <200906010306.n5136t4E020923@sac.sfbay.sun.com> <18979.48826.207639.142420@gargle.gargle.HOWL> <4A23C9A9.2000101@Sun.COM> <4A23CC1F.3040604@Sun.COM> <18979.53011.847291.507810@gargle.gargle.HOWL> <4A23DA8A.70608@Sun.COM> <4A24C8C5.3050903@Sun.COM> <4A259BC0.3040801@sun.com> <18981.48417.257124.786246@gargle.gargle.HOWL> <4A25C3A2.9020800@sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 2115 Actually this case is not with the intention to fix the hotplugged devices bug. Yes, Xorg needs to seteuid(0) back to open the newly plugged devices. But for the existing devices which are already opened, would it be easier and better to just send down a ioctl to switch streams than closing them on switching away and opening them upon switching back with seteuid(0)? I was just following the idea of KIOCSDIRECT ioctl, and at least to me, the shorter of time an application is running with euid 0 the better. Regards, Aaron On 06/03/09 08:28, Alan Coopersmith wrote: > James Carlson wrote: >> Alan Coopersmith writes: >>> That's a bug that was just reported to me in private e-mail while I was out on >>> vacation last week. We need to fix Xorg to setuid back to root before opening >>> hotplugged devices. >> So ... with that bug fixed, does the need for this special ioctl >> remain? Doesn't closing the descriptor and reopening it when needed >> fix the problem? > > Now that I've had a chance to look at it and not just read the e-mail, I'm > trying to determine if that is the correct fix or if the bug is in the kernel > side. The devices are owned by the uid Xorg is running as, due to > logindevperms, but it seems additional privileges are being required by the > kernel drivers (PRIV_SYS_DEVICES) - if it's correct for them to require that, > then I'll work on fixing Xorg to seteuid(0) there. (Xorg has not been made > privilege aware so far since the two states it has needed in the past > are "all privileges" during server/device initialization, and the basic set > provided by seteuid to a non-root user during most of runtime, so there was no > benefit in adding privilege awareness to the code.) > > I was not involved in the decision to create this ioctl, so I can't answer > their motivations or why the project team decided creating an ioctl was > better than adding an additional spot for Xorg to return to uid 0. > -- You know some birds are not meant to be caged, their feathers are just too bright. 电脑这个玩意，你要是没有点好人品还真难成为高手。 From Aaron.Zang@sun.com Tue Jun 2 19:20:30 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n532KTnM005179 for ; Tue, 2 Jun 2009 19:20:30 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n532KNeb005533; Wed, 3 Jun 2009 10:20:28 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKN00A03562CU00@nwk-avmta-1.sfbay.Sun.COM>; Tue, 02 Jun 2009 19:20:26 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKN000NJ5614D60@nwk-avmta-1.sfbay.Sun.COM>; Tue, 02 Jun 2009 19:20:26 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n532KPLe006714; Wed, 03 Jun 2009 02:20:25 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KKN003004ZY5X00@fe-emea-09.sun.com>; Wed, 03 Jun 2009 03:20:25 +0100 (BST) Received: from [129.158.217.200] ([unknown] [129.158.217.200]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KKN002OR55WXE60@fe-emea-09.sun.com>; Wed, 03 Jun 2009 03:20:25 +0100 (BST) Date: Wed, 03 Jun 2009 10:20:38 +0800 From: Aaron Zang Subject: Re: HIDIOCKM[GS]DIRECT ioctls for the USB HID driver [PSARC/2009/329 FastTrack timeout 06/10/2009] In-reply-to: <4A25C7C8.5010400@Sun.COM> Sender: Aaron.Zang@sun.com To: Alan Coopersmith , James Carlson Cc: Darren Kenny , "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, usb-tech@sun.com Message-id: <4A25DDF6.1010801@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <200906010306.n5136t4E020923@sac.sfbay.sun.com> <18979.48826.207639.142420@gargle.gargle.HOWL> <4A23C9A9.2000101@Sun.COM> <4A23CC1F.3040604@Sun.COM> <18979.53011.847291.507810@gargle.gargle.HOWL> <4A23DA8A.70608@Sun.COM> <4A24C8C5.3050903@Sun.COM> <4A259BC0.3040801@sun.com> <18981.48417.257124.786246@gargle.gargle.HOWL> <4A25C3A2.9020800@sun.com> <4A25C7C8.5010400@Sun.COM> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 4116 I'd like to summarize the request or benefit of this pair of ioctls. 1. Switching from Xorg to console while Xorg is running as a non-root user. Of course we can seteuid() to root, close the input devices and reopen them with root euid again while switching back to Xorg. The thing is the handling of VT switching in xfree86 level of Xorg (not down to Solaris level yet) *disables* the input devices instead of closing them. If we were to adopt the close/reopen way, we need to add Solaris specific code to the xfree86 level which seems ugly to me and does not align with the handling of other OSes. Since the upstream is the Xorg community, the better we make our changes in Solaris specific level the better. Plus, not setting euid to root again reduces the risk of potential security attacks. 2. When we are back on console, Xorg is still listening to HAL. If a keyboard is hooked up, Xorg will get the hotplug inform from HAL and thus will open the keyboard via its hid nodes. This would cause the input routed to the external stream even if we are on the console now. Without the ioctl, the keyboard will not be usable until we switch to Xorg. It could be reproduced on my prototype of Xorg vt support. Maybe the Xorg can ignore the input device hotplugging information while on console, and query the info again upon switching back. But this would involve deciding which input devices are old and which are newly plugged. Complex. 3. hid device driver maintains 2 streams, ioctls to control the routing of input between these 2 streams seems to be a natural thing. If we can save the above complexities with these 2 simple ioctls and accomplish a desirable clear architecture, why not? The above are what I could think of till now. Regards, Aaron On 06/03/09 08:46, Aaron Zang wrote: > Actually this case is not with the intention to fix the hotplugged > devices bug. > Yes, Xorg needs to seteuid(0) back to open the newly plugged devices. > But for the existing devices which are already opened, would it be > easier and > better to just send down a ioctl to switch streams than closing them on > switching > away and opening them upon switching back with seteuid(0)? > > I was just following the idea of KIOCSDIRECT ioctl, and at least to me, the > shorter of time an application is running with euid 0 the better. > > > Regards, > Aaron > > > On 06/03/09 08:28, Alan Coopersmith wrote: >> James Carlson wrote: >>> Alan Coopersmith writes: >>>> That's a bug that was just reported to me in private e-mail while I >>>> was out on >>>> vacation last week. We need to fix Xorg to setuid back to root >>>> before opening >>>> hotplugged devices. >>> So ... with that bug fixed, does the need for this special ioctl >>> remain? Doesn't closing the descriptor and reopening it when needed >>> fix the problem? >> >> Now that I've had a chance to look at it and not just read the e-mail, >> I'm >> trying to determine if that is the correct fix or if the bug is in the >> kernel >> side. The devices are owned by the uid Xorg is running as, due to >> logindevperms, but it seems additional privileges are being required >> by the >> kernel drivers (PRIV_SYS_DEVICES) - if it's correct for them to >> require that, >> then I'll work on fixing Xorg to seteuid(0) there. (Xorg has not >> been made >> privilege aware so far since the two states it has needed in the past >> are "all privileges" during server/device initialization, and the >> basic set >> provided by seteuid to a non-root user during most of runtime, so >> there was no >> benefit in adding privilege awareness to the code.) >> >> I was not involved in the decision to create this ioctl, so I can't >> answer >> their motivations or why the project team decided creating an ioctl was >> better than adding an additional spot for Xorg to return to uid 0. >> > -- You know some birds are not meant to be caged, their feathers are just too bright. 电脑这个玩意，你要是没有点好人品还真难成为高手。 From edward.pilatowicz@sun.com Thu Jun 4 19:20:26 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n552KO6r006994 for ; Thu, 4 Jun 2009 19:20:25 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n552K6uL016289; Fri, 5 Jun 2009 10:20:23 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKQ00F07UHY7T00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 04 Jun 2009 19:20:22 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKQ001ZWUHX56A0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 04 Jun 2009 19:20:22 -0700 (PDT) Received: from eng.sun.com (vpn-129-150-150-57.Singapore.Sun.COM [129.150.150.57]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n552KBZv041990; Thu, 04 Jun 2009 19:20:12 -0700 (PDT) Date: Fri, 05 Jun 2009 10:20:10 +0800 From: Edward Pilatowicz Subject: Re: HIDIOCKM[GS]DIRECT ioctls for the USB HID driver [PSARC/2009/329 FastTrack timeout 06/10/2009] In-reply-to: <4A25DDF6.1010801@Sun.COM> To: Aaron Zang Cc: Alan Coopersmith , James Carlson , Darren Kenny , "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, usb-tech@sun.com Message-id: <20090605022010.GB102805@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <4A23C9A9.2000101@Sun.COM> <4A23CC1F.3040604@Sun.COM> <18979.53011.847291.507810@gargle.gargle.HOWL> <4A23DA8A.70608@Sun.COM> <4A24C8C5.3050903@Sun.COM> <4A259BC0.3040801@sun.com> <18981.48417.257124.786246@gargle.gargle.HOWL> <4A25C3A2.9020800@sun.com> <4A25C7C8.5010400@Sun.COM> <4A25DDF6.1010801@Sun.COM> User-Agent: Mutt/1.5.19 (2009-01-05) Status: RO Content-Length: 5777 ok. we've descended into design review here, so i'll toss in my $0.02. wrt the comments below, i think that having the X server close and re-open devices during VT switches is a bad idea. too much complexity and lots of opportunites for ugly failures. i understand that the HIDIOCKM?DIRECT ioctls are modeled after the KIOC?DIRECT, but imho, the suggested ioctls also suffer from some ugly potential failure modes as well. for example, what does the X server do if this ioctl call fails. will the VT we switch to work? or if the X server never issues these ioctls (because it's hung or for some other reason), will we switch to a VT that can't get any input? hence, if at all possible, i'd like the kernel to handle all these plumbing changes automatically rather than requiring additional X server interactions whenever a VT switch occurs. so would it be possible to introduce a new ioctl that the X server could use that would tell the kernel that a given device stream (hid, or /dev/mouse, /dev/kbd, etc) is associated with a specific VT? if we had such an ioctl then when the X server opened an input device it would immediatly issue the ioctl to associate the device with the VT it's using. (if the X server isn't using a VT but is instead running on a dedicated framebuffer, it wouldn't issue the ioctl.) that way, the kernel could keep track of input device stream to VT bindings, and when switching between VTs it could automatically redirect device streams as necessary without requiring any interractions from the X server. thoughts? ed On Wed, Jun 03, 2009 at 10:20:38AM +0800, Aaron Zang wrote: > I'd like to summarize the request or benefit of this pair of ioctls. > > 1. Switching from Xorg to console while Xorg is running as a non-root > user. Of course we can seteuid() to root, close the input devices > and reopen them with root euid again while switching back to Xorg. > The thing is the handling of VT switching in xfree86 level of Xorg > (not down to Solaris level yet) *disables* the input devices instead > of closing them. If we were to adopt the close/reopen way, we need > to add Solaris specific code to the xfree86 level which seems ugly > to me and does not align with the handling of other OSes. Since > the upstream is the Xorg community, the better we make our changes > in Solaris specific level the better. > Plus, not setting euid to root again reduces the risk of potential > security attacks. > > 2. When we are back on console, Xorg is still listening to HAL. > If a keyboard is hooked up, Xorg will get the hotplug inform > from HAL and thus will open the keyboard via its hid nodes. > This would cause the input routed to the external stream even > if we are on the console now. Without the ioctl, the keyboard > will not be usable until we switch to Xorg. It could be reproduced > on my prototype of Xorg vt support. > Maybe the Xorg can ignore the input device hotplugging information > while on console, and query the info again upon switching back. > But this would involve deciding which input devices are old and > which are newly plugged. Complex. > > 3. hid device driver maintains 2 streams, ioctls to control the > routing of input between these 2 streams seems to be a natural > thing. If we can save the above complexities with these 2 simple > ioctls and accomplish a desirable clear architecture, why not? > > > The above are what I could think of till now. > > Regards, > Aaron > > > On 06/03/09 08:46, Aaron Zang wrote: >> Actually this case is not with the intention to fix the hotplugged >> devices bug. >> Yes, Xorg needs to seteuid(0) back to open the newly plugged devices. >> But for the existing devices which are already opened, would it be >> easier and >> better to just send down a ioctl to switch streams than closing them on >> switching >> away and opening them upon switching back with seteuid(0)? >> >> I was just following the idea of KIOCSDIRECT ioctl, and at least to me, the >> shorter of time an application is running with euid 0 the better. >> >> >> Regards, >> Aaron >> >> >> On 06/03/09 08:28, Alan Coopersmith wrote: >>> James Carlson wrote: >>>> Alan Coopersmith writes: >>>>> That's a bug that was just reported to me in private e-mail while >>>>> I was out on >>>>> vacation last week. We need to fix Xorg to setuid back to root >>>>> before opening >>>>> hotplugged devices. >>>> So ... with that bug fixed, does the need for this special ioctl >>>> remain? Doesn't closing the descriptor and reopening it when needed >>>> fix the problem? >>> >>> Now that I've had a chance to look at it and not just read the >>> e-mail, I'm >>> trying to determine if that is the correct fix or if the bug is in >>> the kernel >>> side. The devices are owned by the uid Xorg is running as, due to >>> logindevperms, but it seems additional privileges are being required >>> by the >>> kernel drivers (PRIV_SYS_DEVICES) - if it's correct for them to >>> require that, >>> then I'll work on fixing Xorg to seteuid(0) there. (Xorg has not >>> been made >>> privilege aware so far since the two states it has needed in the past >>> are "all privileges" during server/device initialization, and the >>> basic set >>> provided by seteuid to a non-root user during most of runtime, so >>> there was no >>> benefit in adding privilege awareness to the code.) >>> >>> I was not involved in the decision to create this ioctl, so I can't >>> answer >>> their motivations or why the project team decided creating an ioctl was >>> better than adding an additional spot for Xorg to return to uid 0. >>> >> > > -- > You know some birds are not meant to be caged, their feathers are just too bright. > ???????????????????????? From Aaron.Zang@sun.com Thu Jun 4 20:11:32 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n553BWs7012541 for ; Thu, 4 Jun 2009 20:11:32 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n553BVHW052572; Thu, 4 Jun 2009 21:11:31 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKQ00207WV6MW00@nwk-avmta-1.sfbay.Sun.COM>; Thu, 04 Jun 2009 20:11:30 -0700 (PDT) Received: from gmp-eb-inf-1.sun.com ([192.18.6.21]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKQ001D5WV556E0@nwk-avmta-1.sfbay.Sun.COM>; Thu, 04 Jun 2009 20:11:30 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-1.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n553BTOH015385; Fri, 05 Jun 2009 03:11:29 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KKQ00M00W4A1U00@fe-emea-09.sun.com>; Fri, 05 Jun 2009 04:11:29 +0100 (BST) Received: from [129.158.217.200] ([unknown] [129.158.217.200]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KKQ004ZNWV0VKC0@fe-emea-09.sun.com>; Fri, 05 Jun 2009 04:11:28 +0100 (BST) Date: Fri, 05 Jun 2009 11:11:42 +0800 From: Aaron Zang Subject: Re: HIDIOCKM[GS]DIRECT ioctls for the USB HID driver [PSARC/2009/329 FastTrack timeout 06/10/2009] In-reply-to: <20090605022010.GB102805@eng.sun.com> Sender: Aaron.Zang@sun.com To: Edward Pilatowicz Cc: Alan Coopersmith , James Carlson , Darren Kenny , "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, usb-tech@sun.com Message-id: <4A288CEE.2090707@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <4A23C9A9.2000101@Sun.COM> <4A23CC1F.3040604@Sun.COM> <18979.53011.847291.507810@gargle.gargle.HOWL> <4A23DA8A.70608@Sun.COM> <4A24C8C5.3050903@Sun.COM> <4A259BC0.3040801@sun.com> <18981.48417.257124.786246@gargle.gargle.HOWL> <4A25C3A2.9020800@sun.com> <4A25C7C8.5010400@Sun.COM> <4A25DDF6.1010801@Sun.COM> <20090605022010.GB102805@eng.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 7959 Hey Ed, Yes, as you said, we've descended into design review again. ;) I guess it's because these fast changes/features in Xorg were not foreseeable during the initial design. Your philosophy of more simple interface between the application and the kernel is what I have been seeking. Here is some of my primary thoughts on what you pointed out. Please advise. 1) The HID streams switch ioctls are still needed, even though within the kernel. If the kernel knows which hid device is related to which VT, it (console) still need to tell the hid driver to switch streams when necessary. 2) The following is the current architecture digram. Letting console know about the information in hid level sounds bad to me. The other option is to let conskbd maintain the info of which hid device is related to which VT. This would result in conskbd knowing about console/VT details. Still not good. +---------+ | | | console | | | +----+----+ | | | | | | | | +-+-------+--+ | | conskbd | | +--------+---+ | | | | | +-+---------+--+ | hid | +--------------+ 3) Say Xorg registers which input device it's using during start up to the kernel, and upon receiving that ioctl, the kernel (either console or conskbd) set up a list of input devices for each VT. What if Xorg gets killed and does not have the chance to issue the ioctl to inform the kernel to free the list? Yes, every opened file would be closed, it could be the hid driver tell the list maintainer to update, would it involve complex interfaces between the 3 components -- console/conskbd/hid? Regards, Aaron On 06/05/09 10:20, Edward Pilatowicz wrote: > ok. we've descended into design review here, so i'll toss in my $0.02. > > wrt the comments below, i think that having the X server close and > re-open devices during VT switches is a bad idea. too much complexity > and lots of opportunites for ugly failures. > > i understand that the HIDIOCKM?DIRECT ioctls are modeled after the > KIOC?DIRECT, but imho, the suggested ioctls also suffer from some ugly > potential failure modes as well. for example, what does the X server do > if this ioctl call fails. will the VT we switch to work? or if the X > server never issues these ioctls (because it's hung or for some other > reason), will we switch to a VT that can't get any input? > > hence, if at all possible, i'd like the kernel to handle all these > plumbing changes automatically rather than requiring additional X server > interactions whenever a VT switch occurs. > > so would it be possible to introduce a new ioctl that the X server could > use that would tell the kernel that a given device stream (hid, or > /dev/mouse, /dev/kbd, etc) is associated with a specific VT? if we had > such an ioctl then when the X server opened an input device it would > immediatly issue the ioctl to associate the device with the VT it's > using. (if the X server isn't using a VT but is instead running on a > dedicated framebuffer, it wouldn't issue the ioctl.) that way, the > kernel could keep track of input device stream to VT bindings, and when > switching between VTs it could automatically redirect device streams as > necessary without requiring any interractions from the X server. > > thoughts? > ed > > On Wed, Jun 03, 2009 at 10:20:38AM +0800, Aaron Zang wrote: >> I'd like to summarize the request or benefit of this pair of ioctls. >> >> 1. Switching from Xorg to console while Xorg is running as a non-root >> user. Of course we can seteuid() to root, close the input devices >> and reopen them with root euid again while switching back to Xorg. >> The thing is the handling of VT switching in xfree86 level of Xorg >> (not down to Solaris level yet) *disables* the input devices instead >> of closing them. If we were to adopt the close/reopen way, we need >> to add Solaris specific code to the xfree86 level which seems ugly >> to me and does not align with the handling of other OSes. Since >> the upstream is the Xorg community, the better we make our changes >> in Solaris specific level the better. >> Plus, not setting euid to root again reduces the risk of potential >> security attacks. >> >> 2. When we are back on console, Xorg is still listening to HAL. >> If a keyboard is hooked up, Xorg will get the hotplug inform >> from HAL and thus will open the keyboard via its hid nodes. >> This would cause the input routed to the external stream even >> if we are on the console now. Without the ioctl, the keyboard >> will not be usable until we switch to Xorg. It could be reproduced >> on my prototype of Xorg vt support. >> Maybe the Xorg can ignore the input device hotplugging information >> while on console, and query the info again upon switching back. >> But this would involve deciding which input devices are old and >> which are newly plugged. Complex. >> >> 3. hid device driver maintains 2 streams, ioctls to control the >> routing of input between these 2 streams seems to be a natural >> thing. If we can save the above complexities with these 2 simple >> ioctls and accomplish a desirable clear architecture, why not? >> >> >> The above are what I could think of till now. >> >> Regards, >> Aaron >> >> >> On 06/03/09 08:46, Aaron Zang wrote: >>> Actually this case is not with the intention to fix the hotplugged >>> devices bug. >>> Yes, Xorg needs to seteuid(0) back to open the newly plugged devices. >>> But for the existing devices which are already opened, would it be >>> easier and >>> better to just send down a ioctl to switch streams than closing them on >>> switching >>> away and opening them upon switching back with seteuid(0)? >>> >>> I was just following the idea of KIOCSDIRECT ioctl, and at least to me, the >>> shorter of time an application is running with euid 0 the better. >>> >>> >>> Regards, >>> Aaron >>> >>> >>> On 06/03/09 08:28, Alan Coopersmith wrote: >>>> James Carlson wrote: >>>>> Alan Coopersmith writes: >>>>>> That's a bug that was just reported to me in private e-mail while >>>>>> I was out on >>>>>> vacation last week. We need to fix Xorg to setuid back to root >>>>>> before opening >>>>>> hotplugged devices. >>>>> So ... with that bug fixed, does the need for this special ioctl >>>>> remain? Doesn't closing the descriptor and reopening it when needed >>>>> fix the problem? >>>> Now that I've had a chance to look at it and not just read the >>>> e-mail, I'm >>>> trying to determine if that is the correct fix or if the bug is in >>>> the kernel >>>> side. The devices are owned by the uid Xorg is running as, due to >>>> logindevperms, but it seems additional privileges are being required >>>> by the >>>> kernel drivers (PRIV_SYS_DEVICES) - if it's correct for them to >>>> require that, >>>> then I'll work on fixing Xorg to seteuid(0) there. (Xorg has not >>>> been made >>>> privilege aware so far since the two states it has needed in the past >>>> are "all privileges" during server/device initialization, and the >>>> basic set >>>> provided by seteuid to a non-root user during most of runtime, so >>>> there was no >>>> benefit in adding privilege awareness to the code.) >>>> >>>> I was not involved in the decision to create this ioctl, so I can't >>>> answer >>>> their motivations or why the project team decided creating an ioctl was >>>> better than adding an additional spot for Xorg to return to uid 0. >>>> >> -- >> You know some birds are not meant to be caged, their feathers are just too bright. >> ???????????????????????? -- You know some birds are not meant to be caged, their feathers are just too bright. 电脑这个玩意，你要是没有点好人品还真难成为高手。 From edward.pilatowicz@sun.com Thu Jun 4 23:11:28 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n556BSAX007891 for ; Thu, 4 Jun 2009 23:11:28 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n556B2Ua060514; Fri, 5 Jun 2009 00:11:27 -0600 (MDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKR00C095729J00@brm-avmta-1.central.sun.com>; Fri, 05 Jun 2009 00:11:26 -0600 (MDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKR006W7572H310@brm-avmta-1.central.sun.com>; Fri, 05 Jun 2009 00:11:26 -0600 (MDT) Received: from eng.sun.com (vpn-129-150-150-57.Singapore.Sun.COM [129.150.150.57]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n556BJ4L058372; Thu, 04 Jun 2009 23:11:20 -0700 (PDT) Date: Fri, 05 Jun 2009 14:11:17 +0800 From: Edward Pilatowicz Subject: Re: HIDIOCKM[GS]DIRECT ioctls for the USB HID driver [PSARC/2009/329 FastTrack timeout 06/10/2009] In-reply-to: <4A288CEE.2090707@Sun.COM> To: Aaron Zang Cc: Alan Coopersmith , James Carlson , Darren Kenny , "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, usb-tech@sun.com Message-id: <20090605061117.GG102805@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <18979.53011.847291.507810@gargle.gargle.HOWL> <4A23DA8A.70608@Sun.COM> <4A24C8C5.3050903@Sun.COM> <4A259BC0.3040801@sun.com> <18981.48417.257124.786246@gargle.gargle.HOWL> <4A25C3A2.9020800@sun.com> <4A25C7C8.5010400@Sun.COM> <4A25DDF6.1010801@Sun.COM> <20090605022010.GB102805@eng.sun.com> <4A288CEE.2090707@Sun.COM> User-Agent: Mutt/1.5.19 (2009-01-05) Status: RO Content-Length: 3197 On Fri, Jun 05, 2009 at 11:11:42AM +0800, Aaron Zang wrote: > Hey Ed, > > Yes, as you said, we've descended into design review again. ;) I guess > it's because these fast changes/features in Xorg were not foreseeable > during the initial design. > > Your philosophy of more simple interface between the application and > the kernel is what I have been seeking. > Here is some of my primary thoughts on what you pointed out. Please advise. > > 1) The HID streams switch ioctls are still needed, even though within > the kernel. > If the kernel knows which hid device is related to which VT, it (console) > still need to tell the hid driver to switch streams when necessary. > sure, but then those redirection ioctls are then private kernel interfaces that the xserver doesn't need to know about them. (there by simplifying the xserver and requiring less solaris specific code within the xserver.) > 2) The following is the current architecture digram. > Letting console know about the information in hid level sounds bad to me. > The other option is to let conskbd maintain the info of which hid device > is related to which VT. This would result in conskbd knowing about > console/VT details. Still not good. > > > +---------+ | | > | console | | | > +----+----+ | | > | | | > | | | > +-+-------+--+ | > | conskbd | | > +--------+---+ | > | | > | | > +-+---------+--+ > | hid | > +--------------+ > why doesn't the VT subsystem keep track of which devices are associated with a given VT? if a hid device get's a "vt bind" ioctl it could invoke some VT callback function that tracks the binding/association. then when the VT subsystem get's a request to switch VTs, it could redirect io as needed. > 3) Say Xorg registers which input device it's using during start up to > the kernel, and upon receiving that ioctl, the kernel (either console > or conskbd) set up a list of input devices for each VT. What if > Xorg gets killed and does not have the chance to issue the ioctl to > inform the kernel to free the list? > Yes, every opened file would be closed, it could be the hid driver > tell the list maintainer to update, would it involve complex interfaces > between the 3 components -- console/conskbd/hid? > > this would need to be managed in two ways. first, if a VT is closed (which is what would presumably happen if the X server died), then all device bindings for that VT are torn down. second, whenever a hid device stream is being closed, it could invoke another VT callback function to let the VT subsystem know that any bindings for that device stream should be torn down. all this io-redirection complexity is being introduced by the fact that we want to support VTs. hence, at least to me, it makes sense to have the VT subsystem track and manage this complexity. handling this all automatically in the VT subsystems seems like a much cleaner approach than forcing every VT consumer (like the X server) to manage system VT device io. ed From Aaron.Zang@sun.com Fri Jun 5 00:09:23 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5579NOm026414 for ; Fri, 5 Jun 2009 00:09:23 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n5579NW2021104; Fri, 5 Jun 2009 00:09:23 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKR009057VL6600@nwk-avmta-2.sfbay.sun.com>; Fri, 05 Jun 2009 00:09:21 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKR006P47VGH420@nwk-avmta-2.sfbay.sun.com>; Fri, 05 Jun 2009 00:09:17 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n5579GLo025783; Fri, 05 Jun 2009 07:09:16 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KKR007007H6QQ00@fe-emea-09.sun.com>; Fri, 05 Jun 2009 08:09:16 +0100 (BST) Received: from [129.158.217.200] ([unknown] [129.158.217.200]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KKR00HZT7V53700@fe-emea-09.sun.com>; Fri, 05 Jun 2009 08:09:09 +0100 (BST) Date: Fri, 05 Jun 2009 15:09:23 +0800 From: Aaron Zang Subject: Re: HIDIOCKM[GS]DIRECT ioctls for the USB HID driver [PSARC/2009/329 FastTrack timeout 06/10/2009] In-reply-to: <20090605061117.GG102805@eng.sun.com> Sender: Aaron.Zang@sun.com To: Edward Pilatowicz Cc: Alan Coopersmith , James Carlson , Darren Kenny , "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, usb-tech@sun.com Message-id: <4A28C4A3.6000203@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <18979.53011.847291.507810@gargle.gargle.HOWL> <4A23DA8A.70608@Sun.COM> <4A24C8C5.3050903@Sun.COM> <4A259BC0.3040801@sun.com> <18981.48417.257124.786246@gargle.gargle.HOWL> <4A25C3A2.9020800@sun.com> <4A25C7C8.5010400@Sun.COM> <4A25DDF6.1010801@Sun.COM> <20090605022010.GB102805@eng.sun.com> <4A288CEE.2090707@Sun.COM> <20090605061117.GG102805@eng.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 4357 Hi Ed, I think we are missing some points here. The hid (or other devices) are not only associated to VTs. If these devices are exclusively for console uses, it would be great to bind them to VTs. But how about other appliations which access these devices with no regard to console? Say Xorg opens /dev/usb/hid0, and then a privileged application opens /dev/usb/hid0 and starts to read. If switched back to console, input will be switched to the internal stream silently. The user application may starve if never switching back. At least with the HIDIOC[GS]IOCTLS the user application may switch the input back. The real problem resulting in the Solaris specific code in handling switch in Xorg is because our console/hid... devices are STREAMS based, if they are normal character devices, there won't be any differences. Regards, Aaron On 06/05/09 14:11, Edward Pilatowicz wrote: > On Fri, Jun 05, 2009 at 11:11:42AM +0800, Aaron Zang wrote: >> Hey Ed, >> >> Yes, as you said, we've descended into design review again. ;) I guess >> it's because these fast changes/features in Xorg were not foreseeable >> during the initial design. >> >> Your philosophy of more simple interface between the application and >> the kernel is what I have been seeking. >> Here is some of my primary thoughts on what you pointed out. Please advise. >> >> 1) The HID streams switch ioctls are still needed, even though within >> the kernel. >> If the kernel knows which hid device is related to which VT, it (console) >> still need to tell the hid driver to switch streams when necessary. >> > > sure, but then those redirection ioctls are then private kernel > interfaces that the xserver doesn't need to know about them. (there by > simplifying the xserver and requiring less solaris specific code within > the xserver.) > >> 2) The following is the current architecture digram. >> Letting console know about the information in hid level sounds bad to me. >> The other option is to let conskbd maintain the info of which hid device >> is related to which VT. This would result in conskbd knowing about >> console/VT details. Still not good. >> >> >> +---------+ | | >> | console | | | >> +----+----+ | | >> | | | >> | | | >> +-+-------+--+ | >> | conskbd | | >> +--------+---+ | >> | | >> | | >> +-+---------+--+ >> | hid | >> +--------------+ >> > > why doesn't the VT subsystem keep track of which devices are associated > with a given VT? > > if a hid device get's a "vt bind" ioctl it could invoke some VT callback > function that tracks the binding/association. then when the VT > subsystem get's a request to switch VTs, it could redirect io as needed. > >> 3) Say Xorg registers which input device it's using during start up to >> the kernel, and upon receiving that ioctl, the kernel (either console >> or conskbd) set up a list of input devices for each VT. What if >> Xorg gets killed and does not have the chance to issue the ioctl to >> inform the kernel to free the list? >> Yes, every opened file would be closed, it could be the hid driver >> tell the list maintainer to update, would it involve complex interfaces >> between the 3 components -- console/conskbd/hid? >> >> > > this would need to be managed in two ways. > > first, if a VT is closed (which is what would presumably happen if the > X server died), then all device bindings for that VT are torn down. > > second, whenever a hid device stream is being closed, it could invoke > another VT callback function to let the VT subsystem know that any > bindings for that device stream should be torn down. > > all this io-redirection complexity is being introduced by the fact that > we want to support VTs. hence, at least to me, it makes sense to have > the VT subsystem track and manage this complexity. handling this all > automatically in the VT subsystems seems like a much cleaner approach > than forcing every VT consumer (like the X server) to manage system VT > device io. > > ed -- You know some birds are not meant to be caged, their feathers are just too bright. 电脑这个玩意，你要是没有点好人品还真难成为高手。 From edward.pilatowicz@sun.com Fri Jun 5 00:52:35 2009 Received: from sunmail5.uk.sun.com (sunmail5.UK.Sun.COM [129.156.85.165]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n557qYQ2008068 for ; Fri, 5 Jun 2009 00:52:34 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail5.uk.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n557qVSY022209; Fri, 5 Jun 2009 08:52:33 +0100 (BST) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKR00B0D9VJZO00@nwk-avmta-2.sfbay.sun.com>; Fri, 05 Jun 2009 00:52:31 -0700 (PDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKR006LZ9VJH450@nwk-avmta-2.sfbay.sun.com>; Fri, 05 Jun 2009 00:52:31 -0700 (PDT) Received: from eng.sun.com (vpn-129-150-150-57.Singapore.Sun.COM [129.150.150.57]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n557qMoe032881; Fri, 05 Jun 2009 00:52:24 -0700 (PDT) Date: Fri, 05 Jun 2009 15:52:20 +0800 From: Edward Pilatowicz Subject: Re: HIDIOCKM[GS]DIRECT ioctls for the USB HID driver [PSARC/2009/329 FastTrack timeout 06/10/2009] In-reply-to: <4A28C4A3.6000203@Sun.COM> To: Aaron Zang Cc: Alan Coopersmith , James Carlson , Darren Kenny , "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, usb-tech@sun.com Message-id: <20090605075220.GC103071@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <4A24C8C5.3050903@Sun.COM> <4A259BC0.3040801@sun.com> <18981.48417.257124.786246@gargle.gargle.HOWL> <4A25C3A2.9020800@sun.com> <4A25C7C8.5010400@Sun.COM> <4A25DDF6.1010801@Sun.COM> <20090605022010.GB102805@eng.sun.com> <4A288CEE.2090707@Sun.COM> <20090605061117.GG102805@eng.sun.com> <4A28C4A3.6000203@Sun.COM> User-Agent: Mutt/1.5.19 (2009-01-05) Status: RO Content-Length: 5784 On Fri, Jun 05, 2009 at 03:09:23PM +0800, Aaron Zang wrote: > Hi Ed, > > I think we are missing some points here. it's quite likely that i'm missing a lot of points, so please be patient with me. > The hid (or other devices) are not only associated to VTs. > If these devices are exclusively for console uses, it would > be great to bind them to VTs. > But how about other appliations which access these devices > with no regard to console? > other apps wouldn't issue the binding ioctl, so they would have exclusive access to the device, regardless of vt switching. just the way it works today. do you have any specific examples of these types of applications and how they work? > Say Xorg opens /dev/usb/hid0, and then a privileged application > opens /dev/usb/hid0 and starts to read. If switched back to console, > input will be switched to the internal stream silently. > The user application may starve if never switching back. > At least with the HIDIOC[GS]IOCTLS the user application may switch > the input back. > can you provide an example of this case? it seems to me that if both X and the privileged app try to read from the same stream at the same time, the results will be non-deterministic. (X may get some data and the app may get other bits.) how does this work today? also, do you really expect applications (other than X) to be HIDIOC[GS]IOCTLS aware? if the X server switches intput away from the app with HIDIOCSIOCTLS, how will the app detect that it should be issuing a HIDIOC[GS]IOCTLS to switch back? also, if the application did this wouldn't X also start recieving data again as well? > The real problem resulting in the Solaris specific code in handling > switch in Xorg is because our console/hid... devices are STREAMS > based, if they are normal character devices, there won't be any > differences. > really? i thought the problem was an issue of deciding which consumer of a keyboard/mouse (say console subsystem or an X session) is active, and hence which device consumer should actually be recieving input from the device. is my understanding of the problem correct? if so, how is this decision affected by the device type (streams vs normal character device). ed > Regards, > Aaron > > > On 06/05/09 14:11, Edward Pilatowicz wrote: >> On Fri, Jun 05, 2009 at 11:11:42AM +0800, Aaron Zang wrote: >>> Hey Ed, >>> >>> Yes, as you said, we've descended into design review again. ;) I guess >>> it's because these fast changes/features in Xorg were not foreseeable >>> during the initial design. >>> >>> Your philosophy of more simple interface between the application and >>> the kernel is what I have been seeking. >>> Here is some of my primary thoughts on what you pointed out. Please advise. >>> >>> 1) The HID streams switch ioctls are still needed, even though within >>> the kernel. >>> If the kernel knows which hid device is related to which VT, it (console) >>> still need to tell the hid driver to switch streams when necessary. >>> >> >> sure, but then those redirection ioctls are then private kernel >> interfaces that the xserver doesn't need to know about them. (there by >> simplifying the xserver and requiring less solaris specific code within >> the xserver.) >> >>> 2) The following is the current architecture digram. >>> Letting console know about the information in hid level sounds bad to me. >>> The other option is to let conskbd maintain the info of which hid device >>> is related to which VT. This would result in conskbd knowing about >>> console/VT details. Still not good. >>> >>> >>> +---------+ | | >>> | console | | | >>> +----+----+ | | >>> | | | >>> | | | >>> +-+-------+--+ | >>> | conskbd | | >>> +--------+---+ | >>> | | >>> | | >>> +-+---------+--+ >>> | hid | >>> +--------------+ >>> >> >> why doesn't the VT subsystem keep track of which devices are associated >> with a given VT? >> >> if a hid device get's a "vt bind" ioctl it could invoke some VT callback >> function that tracks the binding/association. then when the VT >> subsystem get's a request to switch VTs, it could redirect io as needed. >> >>> 3) Say Xorg registers which input device it's using during start up to >>> the kernel, and upon receiving that ioctl, the kernel (either console >>> or conskbd) set up a list of input devices for each VT. What if >>> Xorg gets killed and does not have the chance to issue the ioctl to >>> inform the kernel to free the list? >>> Yes, every opened file would be closed, it could be the hid driver >>> tell the list maintainer to update, would it involve complex interfaces >>> between the 3 components -- console/conskbd/hid? >>> >>> >> >> this would need to be managed in two ways. >> >> first, if a VT is closed (which is what would presumably happen if the >> X server died), then all device bindings for that VT are torn down. >> >> second, whenever a hid device stream is being closed, it could invoke >> another VT callback function to let the VT subsystem know that any >> bindings for that device stream should be torn down. >> >> all this io-redirection complexity is being introduced by the fact that >> we want to support VTs. hence, at least to me, it makes sense to have >> the VT subsystem track and manage this complexity. handling this all >> automatically in the VT subsystems seems like a much cleaner approach >> than forcing every VT consumer (like the X server) to manage system VT >> device io. >> >> ed > > -- > You know some birds are not meant to be caged, their feathers are just too bright. > ???????????????????????? From Aaron.Zang@Sun.COM Fri Jun 5 01:30:16 2009 Received: from newsunmail1brm.central.sun.com (newsunmail1brm.Central.Sun.COM [129.147.62.245]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n558UGLJ008800 for ; Fri, 5 Jun 2009 01:30:16 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by newsunmail1brm.central.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n558UCaV007815; Fri, 5 Jun 2009 02:30:16 -0600 (MDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKR00E01BMF9L00@nwk-avmta-2.sfbay.sun.com>; Fri, 05 Jun 2009 01:30:15 -0700 (PDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKR006U1BMEGW70@nwk-avmta-2.sfbay.sun.com>; Fri, 05 Jun 2009 01:30:14 -0700 (PDT) Received: from fe-emea-09.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n558UDvL008325; Fri, 05 Jun 2009 08:30:13 +0000 (GMT) Received: from conversion-daemon.fe-emea-09.sun.com by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KKR00900BD8CX00@fe-emea-09.sun.com>; Fri, 05 Jun 2009 09:30:13 +0100 (BST) Received: from [129.158.217.200] ([unknown] [129.158.217.200]) by fe-emea-09.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KKR00HIOBM73750@fe-emea-09.sun.com>; Fri, 05 Jun 2009 09:30:12 +0100 (BST) Date: Fri, 05 Jun 2009 16:30:26 +0800 From: Aaron Zang Subject: Re: HIDIOCKM[GS]DIRECT ioctls for the USB HID driver [PSARC/2009/329 FastTrack timeout 06/10/2009] In-reply-to: <20090605075220.GC103071@eng.sun.com> Sender: Aaron.Zang@Sun.COM To: Edward Pilatowicz Cc: Alan Coopersmith , James Carlson , Darren Kenny , "Garrett D'Amore - sun microsystems" , PSARC-ext@Sun.COM, usb-tech@Sun.COM Message-id: <4A28D7A2.9010908@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <4A24C8C5.3050903@Sun.COM> <4A259BC0.3040801@sun.com> <18981.48417.257124.786246@gargle.gargle.HOWL> <4A25C3A2.9020800@sun.com> <4A25C7C8.5010400@Sun.COM> <4A25DDF6.1010801@Sun.COM> <20090605022010.GB102805@eng.sun.com> <4A288CEE.2090707@Sun.COM> <20090605061117.GG102805@eng.sun.com> <4A28C4A3.6000203@Sun.COM> <20090605075220.GC103071@eng.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 7676 On 06/05/09 15:52, Edward Pilatowicz wrote: > On Fri, Jun 05, 2009 at 03:09:23PM +0800, Aaron Zang wrote: >> Hi Ed, >> >> I think we are missing some points here. > > it's quite likely that i'm missing a lot of points, so please be patient > with me. > >> The hid (or other devices) are not only associated to VTs. >> If these devices are exclusively for console uses, it would >> be great to bind them to VTs. >> But how about other appliations which access these devices >> with no regard to console? >> > > other apps wouldn't issue the binding ioctl, so they would have > exclusive access to the device, regardless of vt switching. just the > way it works today. > Other applications may share the same devices with Xorg which are bind to certain VT by Xorg. > do you have any specific examples of these types of applications and how > they work? > No. But occasionally I need to "cat /dev/usb/hid0" to see if my keyboard is still working. If a user does that on purpose, he probably won't want to lose input, especially for a long time. That might not be a very proper example. Just the idea of Xorg binding shared devices to VTs seems very weird to me. >> Say Xorg opens /dev/usb/hid0, and then a privileged application >> opens /dev/usb/hid0 and starts to read. If switched back to console, >> input will be switched to the internal stream silently. >> The user application may starve if never switching back. >> At least with the HIDIOC[GS]IOCTLS the user application may switch >> the input back. >> > > can you provide an example of this case? > > it seems to me that if both X and the privileged app try to read from > the same stream at the same time, the results will be non-deterministic. > (X may get some data and the app may get other bits.) how does this > work today? > Yes, if they are both reading the results will be non-deterministic. When switched away, Xorg may not be reading input, though it still keeps the file open, but the other application may still reading. Even when Xorg is active, it polls the input devices, so if there are other applications reading the same input device, the input would likely be read by the application. I tried "/dev/usb/hid0" in my gnome terminal, it seems this thread gets all the input since the characters echoed on the terminal is not recognizable. > also, do you really expect applications (other than X) to be > HIDIOC[GS]IOCTLS aware? if the X server switches intput away from the > app with HIDIOCSIOCTLS, how will the app detect that it should be > issuing a HIDIOC[GS]IOCTLS to switch back? also, if the application did > this wouldn't X also start recieving data again as well? > My thoughts are if we switch streams automatically during switch if would be UNFAIR for other applications not be able to switch them back. There might not be any existing well known applications do that, but we can not rule out the possibility, especially in the future. The application could set up a timer, if it expires, it could check the direction and if switched away, switched back, it is privileged application, it could do anything it likes. >> The real problem resulting in the Solaris specific code in handling >> switch in Xorg is because our console/hid... devices are STREAMS >> based, if they are normal character devices, there won't be any >> differences. >> > > really? i thought the problem was an issue of deciding which consumer > of a keyboard/mouse (say console subsystem or an X session) is active, > and hence which device consumer should actually be recieving input from > the device. is my understanding of the problem correct? if so, how is > this decision affected by the device type (streams vs normal character > device). > If not STREAMS based, you do not need to switch streams. Just stop reading the input devices if switched away. Regards, Aaron > ed > >> Regards, >> Aaron >> >> >> On 06/05/09 14:11, Edward Pilatowicz wrote: >>> On Fri, Jun 05, 2009 at 11:11:42AM +0800, Aaron Zang wrote: >>>> Hey Ed, >>>> >>>> Yes, as you said, we've descended into design review again. ;) I guess >>>> it's because these fast changes/features in Xorg were not foreseeable >>>> during the initial design. >>>> >>>> Your philosophy of more simple interface between the application and >>>> the kernel is what I have been seeking. >>>> Here is some of my primary thoughts on what you pointed out. Please advise. >>>> >>>> 1) The HID streams switch ioctls are still needed, even though within >>>> the kernel. >>>> If the kernel knows which hid device is related to which VT, it (console) >>>> still need to tell the hid driver to switch streams when necessary. >>>> >>> sure, but then those redirection ioctls are then private kernel >>> interfaces that the xserver doesn't need to know about them. (there by >>> simplifying the xserver and requiring less solaris specific code within >>> the xserver.) >>> >>>> 2) The following is the current architecture digram. >>>> Letting console know about the information in hid level sounds bad to me. >>>> The other option is to let conskbd maintain the info of which hid device >>>> is related to which VT. This would result in conskbd knowing about >>>> console/VT details. Still not good. >>>> >>>> >>>> +---------+ | | >>>> | console | | | >>>> +----+----+ | | >>>> | | | >>>> | | | >>>> +-+-------+--+ | >>>> | conskbd | | >>>> +--------+---+ | >>>> | | >>>> | | >>>> +-+---------+--+ >>>> | hid | >>>> +--------------+ >>>> >>> why doesn't the VT subsystem keep track of which devices are associated >>> with a given VT? >>> >>> if a hid device get's a "vt bind" ioctl it could invoke some VT callback >>> function that tracks the binding/association. then when the VT >>> subsystem get's a request to switch VTs, it could redirect io as needed. >>> >>>> 3) Say Xorg registers which input device it's using during start up to >>>> the kernel, and upon receiving that ioctl, the kernel (either console >>>> or conskbd) set up a list of input devices for each VT. What if >>>> Xorg gets killed and does not have the chance to issue the ioctl to >>>> inform the kernel to free the list? >>>> Yes, every opened file would be closed, it could be the hid driver >>>> tell the list maintainer to update, would it involve complex interfaces >>>> between the 3 components -- console/conskbd/hid? >>>> >>>> >>> this would need to be managed in two ways. >>> >>> first, if a VT is closed (which is what would presumably happen if the >>> X server died), then all device bindings for that VT are torn down. >>> >>> second, whenever a hid device stream is being closed, it could invoke >>> another VT callback function to let the VT subsystem know that any >>> bindings for that device stream should be torn down. >>> >>> all this io-redirection complexity is being introduced by the fact that >>> we want to support VTs. hence, at least to me, it makes sense to have >>> the VT subsystem track and manage this complexity. handling this all >>> automatically in the VT subsystems seems like a much cleaner approach >>> than forcing every VT consumer (like the X server) to manage system VT >>> device io. >>> >>> ed >> -- >> You know some birds are not meant to be caged, their feathers are just too bright. >> ???????????????????????? -- You know some birds are not meant to be caged, their feathers are just too bright. 电脑这个玩意，你要是没有点好人品还真难成为高手。 From Aaron.Zang@sun.com Fri Jun 5 18:32:47 2009 Received: from sunmail4.singapore.sun.com (sunmail4.Singapore.Sun.COM [129.158.71.19]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n561Wkaa023177 for ; Fri, 5 Jun 2009 18:32:47 -0700 (PDT) Received: from nwk-avmta-1.SFBay.Sun.COM (nwk-avmta-1.SFBay.Sun.COM [129.146.11.74]) by sunmail4.singapore.sun.com (8.13.4+Sun/8.13.3/ENSMAIL,v2.2) with ESMTP id n561Wjh5008561; Sat, 6 Jun 2009 09:32:45 +0800 (SGT) Received: from pmxchannel-daemon.nwk-avmta-1.sfbay.Sun.COM by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKS00D03MYK0Z00@nwk-avmta-1.sfbay.Sun.COM>; Fri, 05 Jun 2009 18:32:44 -0700 (PDT) Received: from sineb-mail-1.sun.com ([192.18.19.6]) by nwk-avmta-1.sfbay.Sun.COM (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKS00CXRMYI2910@nwk-avmta-1.sfbay.Sun.COM>; Fri, 05 Jun 2009 18:32:43 -0700 (PDT) Received: from fe-apac-05.sun.com (fe-apac-05.sun.com [192.18.19.176] (may be forged)) by sineb-mail-1.sun.com (8.13.6+Sun/8.12.9) with ESMTP id n561Wg4I002332; Sat, 06 Jun 2009 01:32:42 +0000 (GMT) Received: from conversion-daemon.mail-apac.sun.com by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KKS00G00MCRP200@mail-apac.sun.com>; Sat, 06 Jun 2009 09:32:42 +0800 (SGT) Received: from [129.150.144.12] ([unknown] [129.150.144.12]) by mail-apac.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KKS00H8WMYG4550@mail-apac.sun.com>; Sat, 06 Jun 2009 09:32:42 +0800 (SGT) Date: Sat, 06 Jun 2009 09:32:41 +0800 From: Aaron Zang Subject: Re: HIDIOCKM[GS]DIRECT ioctls for the USB HID driver [PSARC/2009/329 FastTrack timeout 06/10/2009] In-reply-to: <4A28D7A2.9010908@Sun.COM> Sender: Aaron.Zang@sun.com To: Edward Pilatowicz Cc: Alan Coopersmith , James Carlson , Darren Kenny , "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, usb-tech@sun.com Message-id: <4A29C739.1020200@Sun.COM> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 References: <4A24C8C5.3050903@Sun.COM> <4A259BC0.3040801@sun.com> <18981.48417.257124.786246@gargle.gargle.HOWL> <4A25C3A2.9020800@sun.com> <4A25C7C8.5010400@Sun.COM> <4A25DDF6.1010801@Sun.COM> <20090605022010.GB102805@eng.sun.com> <4A288CEE.2090707@Sun.COM> <20090605061117.GG102805@eng.sun.com> <4A28C4A3.6000203@Sun.COM> <20090605075220.GC103071@eng.sun.com> <4A28D7A2.9010908@Sun.COM> User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) Status: RO Content-Length: 9330 Hi Ed, I think I'd better make my justifications of not binding hid devices to VTs clear so that they won't not buried under the details. These devices are shared devices, not for exclusive usage of Xorg or VT, Although Xorg and console might be the biggest consumers. The actually users/applications should get to decide which stream should get the input. We kernel should never make the decision and assumptions on behave of them. If they are exclusively used by console and Xorg, I will be more than happy to bind them to VTs. I just thought another small scenario which may explain my concerns a little bit. There are 2 keyboards -- K1 (/dev/usb/hid0) and K2 (/dev/usb/hid1) on the system. On /dev/vt/6 which is a text console session, the root user wrote an application to listen to /dev/usb/hid0 with the purpose of debugging or whatever. Xorg starts on /dev/vt/7, and it is configured to use keyboard1 and keyboard2. So it registers K1 and K2 to the kernel so that both of them are bind to VT7. The user switches Xorg to VT6, during the switching, since K1 and K2 are bond to VT7, and VT6 is console session, the streams of K1 and K2 are switched to the internal one. The user process which is listening to /dev/usb/hid0 will starve on /dev/vt/6 though K1 has inputs. With HIDIOCKM[GS]DIRECT ioctls the user application at least have an option to switch the stream back by either set up a timer as I described before or using NONBLOCK read. If I was wrong, please correct me. Regards, Aaron Aaron Zang wrote: > > > On 06/05/09 15:52, Edward Pilatowicz wrote: >> On Fri, Jun 05, 2009 at 03:09:23PM +0800, Aaron Zang wrote: >>> Hi Ed, >>> >>> I think we are missing some points here. >> >> it's quite likely that i'm missing a lot of points, so please be patient >> with me. >> >>> The hid (or other devices) are not only associated to VTs. >>> If these devices are exclusively for console uses, it would >>> be great to bind them to VTs. >>> But how about other appliations which access these devices >>> with no regard to console? >>> >> >> other apps wouldn't issue the binding ioctl, so they would have >> exclusive access to the device, regardless of vt switching. just the >> way it works today. >> > > Other applications may share the same devices with Xorg which are bind > to certain VT by Xorg. > > >> do you have any specific examples of these types of applications and how >> they work? >> > > No. But occasionally I need to "cat /dev/usb/hid0" to see if my keyboard > is still working. > If a user does that on purpose, he probably won't want to lose > input, especially for a long time. > That might not be a very proper example. Just the idea of Xorg binding > shared > devices to VTs seems very weird to me. > >>> Say Xorg opens /dev/usb/hid0, and then a privileged application >>> opens /dev/usb/hid0 and starts to read. If switched back to console, >>> input will be switched to the internal stream silently. >>> The user application may starve if never switching back. >>> At least with the HIDIOC[GS]IOCTLS the user application may switch >>> the input back. >>> >> >> can you provide an example of this case? >> >> it seems to me that if both X and the privileged app try to read from >> the same stream at the same time, the results will be non-deterministic. >> (X may get some data and the app may get other bits.) how does this >> work today? >> > > Yes, if they are both reading the results will be non-deterministic. > When switched away, Xorg may not be reading input, though it still keeps > the file open, but the other application may still reading. > Even when Xorg is active, it polls the input devices, so if there > are other applications reading the same input device, the input would > likely be read by the application. > I tried "/dev/usb/hid0" in my gnome terminal, it seems this thread > gets all the input since the characters echoed on the terminal is > not recognizable. > >> also, do you really expect applications (other than X) to be >> HIDIOC[GS]IOCTLS aware? if the X server switches intput away from the >> app with HIDIOCSIOCTLS, how will the app detect that it should be >> issuing a HIDIOC[GS]IOCTLS to switch back? also, if the application did >> this wouldn't X also start recieving data again as well? >> > > My thoughts are if we switch streams automatically during switch > if would be UNFAIR for other applications not be able to switch them back. > There might not be any existing well known applications do that, but > we can not rule out the possibility, especially in the future. > > The application could set up a timer, if it expires, it could > check the direction and if switched away, switched back, it is > privileged application, it could do anything it likes. > > >>> The real problem resulting in the Solaris specific code in handling >>> switch in Xorg is because our console/hid... devices are STREAMS >>> based, if they are normal character devices, there won't be any >>> differences. >>> >> >> really? i thought the problem was an issue of deciding which consumer >> of a keyboard/mouse (say console subsystem or an X session) is active, >> and hence which device consumer should actually be recieving input from >> the device. is my understanding of the problem correct? if so, how is >> this decision affected by the device type (streams vs normal character >> device). >> > > If not STREAMS based, you do not need to switch streams. Just stop > reading the input devices if switched away. > > Regards, > Aaron > > >> ed >> >>> Regards, >>> Aaron >>> >>> >>> On 06/05/09 14:11, Edward Pilatowicz wrote: >>>> On Fri, Jun 05, 2009 at 11:11:42AM +0800, Aaron Zang wrote: >>>>> Hey Ed, >>>>> >>>>> Yes, as you said, we've descended into design review again. ;) I guess >>>>> it's because these fast changes/features in Xorg were not foreseeable >>>>> during the initial design. >>>>> >>>>> Your philosophy of more simple interface between the application and >>>>> the kernel is what I have been seeking. >>>>> Here is some of my primary thoughts on what you pointed out. Please >>>>> advise. >>>>> >>>>> 1) The HID streams switch ioctls are still needed, even though within >>>>> the kernel. >>>>> If the kernel knows which hid device is related to which VT, it >>>>> (console) >>>>> still need to tell the hid driver to switch streams when necessary. >>>>> >>>> sure, but then those redirection ioctls are then private kernel >>>> interfaces that the xserver doesn't need to know about them. (there by >>>> simplifying the xserver and requiring less solaris specific code within >>>> the xserver.) >>>> >>>>> 2) The following is the current architecture digram. >>>>> Letting console know about the information in hid level sounds >>>>> bad to me. >>>>> The other option is to let conskbd maintain the info of which >>>>> hid device >>>>> is related to which VT. This would result in conskbd knowing about >>>>> console/VT details. Still not good. >>>>> >>>>> >>>>> +---------+ | | >>>>> | console | | | >>>>> +----+----+ | | >>>>> | | | >>>>> | | | >>>>> +-+-------+--+ | >>>>> | conskbd | | >>>>> +--------+---+ | >>>>> | | >>>>> | | >>>>> +-+---------+--+ >>>>> | hid | >>>>> +--------------+ >>>>> >>>> why doesn't the VT subsystem keep track of which devices are associated >>>> with a given VT? >>>> >>>> if a hid device get's a "vt bind" ioctl it could invoke some VT >>>> callback >>>> function that tracks the binding/association. then when the VT >>>> subsystem get's a request to switch VTs, it could redirect io as >>>> needed. >>>> >>>>> 3) Say Xorg registers which input device it's using during start up to >>>>> the kernel, and upon receiving that ioctl, the kernel (either >>>>> console >>>>> or conskbd) set up a list of input devices for each VT. What if >>>>> Xorg gets killed and does not have the chance to issue the ioctl to >>>>> inform the kernel to free the list? >>>>> Yes, every opened file would be closed, it could be the hid driver >>>>> tell the list maintainer to update, would it involve complex >>>>> interfaces >>>>> between the 3 components -- console/conskbd/hid? >>>>> >>>>> >>>> this would need to be managed in two ways. >>>> >>>> first, if a VT is closed (which is what would presumably happen if the >>>> X server died), then all device bindings for that VT are torn down. >>>> >>>> second, whenever a hid device stream is being closed, it could invoke >>>> another VT callback function to let the VT subsystem know that any >>>> bindings for that device stream should be torn down. >>>> >>>> all this io-redirection complexity is being introduced by the fact that >>>> we want to support VTs. hence, at least to me, it makes sense to have >>>> the VT subsystem track and manage this complexity. handling this all >>>> automatically in the VT subsystems seems like a much cleaner approach >>>> than forcing every VT consumer (like the X server) to manage system VT >>>> device io. >>>> >>>> ed >>> -- >>> You know some birds are not meant to be caged, their feathers are >>> just too bright. >>> ???????????????????????? > From edward.pilatowicz@sun.com Mon Jun 8 12:47:45 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n58Jljld017431 for ; Mon, 8 Jun 2009 12:47:45 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n58Jld86000134; Mon, 8 Jun 2009 12:47:45 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKX0021TQZKWG00@brm-avmta-1.central.sun.com>; Mon, 08 Jun 2009 13:47:44 -0600 (MDT) Received: from dm-sfbay-02.sfbay.sun.com ([129.146.11.31]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKX008TVQZJF3E0@brm-avmta-1.central.sun.com>; Mon, 08 Jun 2009 13:47:43 -0600 (MDT) Received: from eng.sun.com (cretaceous.SFBay.Sun.COM [129.146.17.59]) by dm-sfbay-02.sfbay.sun.com (8.13.8+Sun/8.13.8/ENSMAIL,v2.2) with ESMTP id n58Jldik063881; Mon, 08 Jun 2009 12:47:39 -0700 (PDT) Date: Mon, 08 Jun 2009 12:47:38 -0700 From: Edward Pilatowicz Subject: Re: HIDIOCKM[GS]DIRECT ioctls for the USB HID driver [PSARC/2009/329 FastTrack timeout 06/10/2009] In-reply-to: <4A29C739.1020200@Sun.COM> To: Aaron Zang Cc: Alan Coopersmith , James Carlson , Darren Kenny , "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, usb-tech@sun.com Message-id: <20090608194738.GC572220@eng.sun.com> MIME-version: 1.0 Content-type: text/plain; charset=us-ascii Content-transfer-encoding: 7BIT Content-disposition: inline X-PMX-Version: 5.4.1.325704 References: <4A25C3A2.9020800@sun.com> <4A25C7C8.5010400@Sun.COM> <4A25DDF6.1010801@Sun.COM> <20090605022010.GB102805@eng.sun.com> <4A288CEE.2090707@Sun.COM> <20090605061117.GG102805@eng.sun.com> <4A28C4A3.6000203@Sun.COM> <20090605075220.GC103071@eng.sun.com> <4A28D7A2.9010908@Sun.COM> <4A29C739.1020200@Sun.COM> User-Agent: Mutt/1.5.19 (2009-01-05) Status: RO Content-Length: 3337 On Sat, Jun 06, 2009 at 09:32:41AM +0800, Aaron Zang wrote: > Hi Ed, > > I think I'd better make my justifications of not binding hid devices > to VTs clear so that they won't not buried under the details. > > These devices are shared devices, not for exclusive usage of Xorg > or VT, Although Xorg and console might be the biggest consumers. > The actually users/applications should get to decide which stream > should get the input. We kernel should never make the decision > and assumptions on behave of them. > If they are exclusively used by console and Xorg, I will be more > than happy to bind them to VTs. > > I just thought another small scenario which may explain my concerns > a little bit. > > There are 2 keyboards -- K1 (/dev/usb/hid0) and K2 (/dev/usb/hid1) > on the system. > On /dev/vt/6 which is a text console session, the root user > wrote an application to listen to /dev/usb/hid0 with the purpose > of debugging or whatever. > so imho, your optimizing / designing these interfaces for a very uncommon use case. you're a kernel developer, so accessing hid0 devices for debugging is a common use case for you, but do you really think that accessing hid devices directly is a common use case for most (any?) solaris users? > Xorg starts on /dev/vt/7, and it is configured to use keyboard1 > and keyboard2. So it registers K1 and K2 to the kernel > so that both of them are bind to VT7. so this scenario is already fundamentally broken. we have two entities listening to the same hid0 device, which you told me earlier will result in non-deterministic behavior. so now your trying to support a scenario where X (or the app) can't work correctly. > The user switches Xorg to VT6, during the switching, since > K1 and K2 are bond to VT7, and VT6 is console session, the > streams of K1 and K2 are switched to the internal one. > this is the same thing that would happen if the X server issued your propsed ioctls. > The user process which is listening to /dev/usb/hid0 will starve > on /dev/vt/6 though K1 has inputs. > With HIDIOCKM[GS]DIRECT ioctls the user application at least > have an option to switch the stream back by either set up a > timer as I described before or using NONBLOCK read. > sure. if the (fundamentally broken) application is aware that streams output can randomly stop, it could use these ioctls to switch data back. now the (fundamentally broken) app can become even more complex, with timeouts and async IO all to manage the fact that input might randomly stop. for your scenario above, it seems that what you really want it a way for an application to get dedicated access to a hid devices. if your app (debugging or whatever) could request dedicated access, then it could be written correctly, since it would never share the device with the X server, and additionally the hid data could never be randomly re-directed somewhere else while the device is in use. > If I was wrong, please correct me. > i don't think either of us is wrong, we just have a fundamental difference of opinion. :) i think these interfaces push unnecessary complexity into the X server. that said, i think we've beaten this dead horse enough. you've already got your +1 and you've got sign off from the X folks for adding these interfaces. hence, we should just agree to disagree on this issue. ed From Aaron.Zang@sun.com Mon Jun 8 18:30:34 2009 Received: from sunmail3mpk.sfbay.sun.com (sunmail3mpk.SFBay.Sun.COM [129.146.11.52]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n591UYC0026414 for ; Mon, 8 Jun 2009 18:30:34 -0700 (PDT) Received: from brm-avmta-1.central.sun.com (brm-avmta-1.Central.Sun.COM [129.147.4.11]) by sunmail3mpk.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n591UXd7011609; Mon, 8 Jun 2009 18:30:33 -0700 (PDT) Received: from pmxchannel-daemon.brm-avmta-1.central.sun.com by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KKY00G0T6UVA900@brm-avmta-1.central.sun.com>; Mon, 08 Jun 2009 19:30:31 -0600 (MDT) Received: from gmp-eb-inf-2.sun.com ([192.18.6.24]) by brm-avmta-1.central.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KKY00L5P6UTZI80@brm-avmta-1.central.sun.com>; Mon, 08 Jun 2009 19:30:30 -0600 (MDT) Received: from fe-emea-10.sun.com (gmp-eb-lb-1-fe3.eu.sun.com [192.18.6.10]) by gmp-eb-inf-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n591UTWS016068; Tue, 09 Jun 2009 01:30:29 +0000 (GMT) Received: from conversion-daemon.fe-emea-10.sun.com by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KKY00C006TJ7S00@fe-emea-10.sun.com>; Tue, 09 Jun 2009 02:30:29 +0100 (BST) Received: from [129.158.217.200] ([unknown] [129.158.217.200]) by fe-emea-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KKY00CWL6ULRKA0@fe-emea-10.sun.com>; Tue, 09 Jun 2009 02:30:29 +0100 (BST) Date: Tue, 09 Jun 2009 09:30:39 +0800 From: Aaron Zang Subject: Re: HIDIOCKM[GS]DIRECT ioctls for the USB HID driver [PSARC/2009/329 FastTrack timeout 06/10/2009] In-reply-to: <20090608194738.GC572220@eng.sun.com> Sender: Aaron.Zang@sun.com To: Edward Pilatowicz Cc: Alan Coopersmith , James Carlson , Darren Kenny , "Garrett D'Amore - sun microsystems" , PSARC-ext@sun.com, usb-tech@sun.com Message-id: <4A2DBB3F.3010507@Sun.COM> MIME-version: 1.0 Content-type: text/plain; format=flowed; charset=UTF-8 Content-transfer-encoding: 8BIT X-PMX-Version: 5.4.1.325704 References: <4A25C3A2.9020800@sun.com> <4A25C7C8.5010400@Sun.COM> <4A25DDF6.1010801@Sun.COM> <20090605022010.GB102805@eng.sun.com> <4A288CEE.2090707@Sun.COM> <20090605061117.GG102805@eng.sun.com> <4A28C4A3.6000203@Sun.COM> <20090605075220.GC103071@eng.sun.com> <4A28D7A2.9010908@Sun.COM> <4A29C739.1020200@Sun.COM> <20090608194738.GC572220@eng.sun.com> User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 3718 Thanks for accepting the differences. Regards, Aaron On 06/09/09 03:47, Edward Pilatowicz wrote: > On Sat, Jun 06, 2009 at 09:32:41AM +0800, Aaron Zang wrote: >> Hi Ed, >> >> I think I'd better make my justifications of not binding hid devices >> to VTs clear so that they won't not buried under the details. >> >> These devices are shared devices, not for exclusive usage of Xorg >> or VT, Although Xorg and console might be the biggest consumers. >> The actually users/applications should get to decide which stream >> should get the input. We kernel should never make the decision >> and assumptions on behave of them. >> If they are exclusively used by console and Xorg, I will be more >> than happy to bind them to VTs. >> >> I just thought another small scenario which may explain my concerns >> a little bit. >> >> There are 2 keyboards -- K1 (/dev/usb/hid0) and K2 (/dev/usb/hid1) >> on the system. >> On /dev/vt/6 which is a text console session, the root user >> wrote an application to listen to /dev/usb/hid0 with the purpose >> of debugging or whatever. >> > > so imho, your optimizing / designing these interfaces for a very > uncommon use case. you're a kernel developer, so accessing hid0 devices > for debugging is a common use case for you, but do you really think that > accessing hid devices directly is a common use case for most (any?) > solaris users? > >> Xorg starts on /dev/vt/7, and it is configured to use keyboard1 >> and keyboard2. So it registers K1 and K2 to the kernel >> so that both of them are bind to VT7. > > so this scenario is already fundamentally broken. we have two entities > listening to the same hid0 device, which you told me earlier will result > in non-deterministic behavior. so now your trying to support a scenario > where X (or the app) can't work correctly. > >> The user switches Xorg to VT6, during the switching, since >> K1 and K2 are bond to VT7, and VT6 is console session, the >> streams of K1 and K2 are switched to the internal one. >> > > this is the same thing that would happen if the X server issued your > propsed ioctls. > >> The user process which is listening to /dev/usb/hid0 will starve >> on /dev/vt/6 though K1 has inputs. >> With HIDIOCKM[GS]DIRECT ioctls the user application at least >> have an option to switch the stream back by either set up a >> timer as I described before or using NONBLOCK read. >> > > sure. if the (fundamentally broken) application is aware that streams > output can randomly stop, it could use these ioctls to switch data back. > now the (fundamentally broken) app can become even more complex, with > timeouts and async IO all to manage the fact that input might randomly > stop. > > for your scenario above, it seems that what you really want it a way for > an application to get dedicated access to a hid devices. if your app > (debugging or whatever) could request dedicated access, then it could be > written correctly, since it would never share the device with the X > server, and additionally the hid data could never be randomly > re-directed somewhere else while the device is in use. > >> If I was wrong, please correct me. >> > > i don't think either of us is wrong, we just have a fundamental > difference of opinion. :) > > i think these interfaces push unnecessary complexity into the X server. > that said, i think we've beaten this dead horse enough. you've already > got your +1 and you've got sign off from the X folks for adding these > interfaces. hence, we should just agree to disagree on this issue. > > ed -- You know some birds are not meant to be caged, their feathers are just too bright. 电脑这个玩意，你要是没有点好人品还真难成为高手。 From gdamore@Sun.COM Wed Jun 17 17:19:11 2009 Received: from sunmail2sca.sfbay.sun.com (sunmail2sca.SFBay.Sun.COM [129.145.155.234]) by sac.sfbay.sun.com (8.13.8+Sun/8.13.8) with ESMTP id n5I0JBEZ012248 for ; Wed, 17 Jun 2009 17:19:11 -0700 (PDT) Received: from nwk-avmta-2.sfbay.sun.com (nwk-avmta-2.SFBay.Sun.COM [129.145.155.6]) by sunmail2sca.sfbay.sun.com (8.13.7+Sun/8.13.7/ENSMAIL,v2.2) with ESMTP id n5I0J8MY015119 for <@sunmail2sca.sfbay.sun.com:PSARC-ext@sun.com>; Wed, 17 Jun 2009 17:19:11 -0700 (PDT) Received: from pmxchannel-daemon.nwk-avmta-2.sfbay.sun.com by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) id <0KLE00F21RJY1F00@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Jun 2009 17:19:10 -0700 (PDT) Received: from sca-es-mail-2.sun.com ([192.18.43.133]) by nwk-avmta-2.sfbay.sun.com (Sun Java System Messaging Server 6.2-3.04 (built Jul 15 2005)) with ESMTP id <0KLE003S6RJVHC80@nwk-avmta-2.sfbay.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Jun 2009 17:19:07 -0700 (PDT) Received: from fe-sfbay-10.sun.com ([192.18.43.129]) by sca-es-mail-2.sun.com (8.13.7+Sun/8.12.9) with ESMTP id n5I0J79p004521 for ; Wed, 17 Jun 2009 17:19:07 -0700 (PDT) Received: from conversion-daemon.fe-sfbay-10.sun.com by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) id <0KLE00I00R1LZH00@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Jun 2009 17:19:07 -0700 (PDT) Received: from [192.168.251.11] ([unknown] [76.93.15.33]) by fe-sfbay-10.sun.com (Sun Java(tm) System Messaging Server 7u2-7.02 64bit (built Apr 16 2009)) with ESMTPSA id <0KLE00HOCRJUSOF0@fe-sfbay-10.sun.com> for PSARC-ext@sun.com (ORCPT PSARC-ext@sun.com); Wed, 17 Jun 2009 17:19:06 -0700 (PDT) Date: Wed, 17 Jun 2009 17:19:06 -0700 From: "Garrett D'Amore" Subject: PSARC 2009/329 HIDIOCKM[GS]DIRECT ioctls for the USB HID driver Sender: Garrett.Damore@Sun.COM To: PSARC-ext Message-id: <4A3987FA.1000102@sun.com> MIME-version: 1.0 Content-type: text/plain; CHARSET=US-ASCII; format=flowed Content-transfer-encoding: 7BIT X-PMX-Version: 5.4.1.325704 User-Agent: Thunderbird 2.0.0.18 (X11/20081201) Status: RO Content-Length: 56 This case was approved at PSARC today. -- Garrett