On Tue, Sep 30, 2003 at 12:51:55PM -0500, Bryan W. Headley wrote: >David Dawes wrote: >> On Mon, Sep 29, 2003 at 09:52:16AM -0500, Bryan W. Headley wrote: >> >>>David, >>> >>>How is the work on the XF86Config parser coming? I ask because I noticed >>>that the 'Option "Device" "/dev/input/event?"' is getting weird, like I >>>thought it would when we were discussing Input System improvements. >>> >>>Specifically, my tablet seems to have chosen for it different >>>/dev/input/event? paths where it is mapped to during boot-up. For >>>several times, it's mapped to /dev/input/event2, then after a subsequent >>>reboot, it moves to /dev/input/event1 for awhile... >> >> >> In the short term, can whatever daemon on Linux handles plug events be >> configured to point some symlink to the correct device? If so, you could >> refer to that in the XF86Config file? >> > >I said nothing about plug events... the tablet was there during bootup. >The pseudo /dev entry chosen for the input device <i>changes</i>, >depending on I dunno what. But we both know the hotplug environment adds >to this fun.
I was assuming that there would be an implicit plug event at boot time. I'm guessing based on how I've seen other systems work. I haven't had an opportunity to play with this stuff on recent Linux kernels yet. >/dev/input/event2 -> /somepath/hardware-mapping/usb/wacom/0x1234/1 > >(Where, I know it's a USB tablet; the tablet knows it's a wacom with a >productId of 0x1234, and that this is the first tablet). > >At which point, I'd argue against the /dev/input/event2 path being used >anywhere. Because no-one knows what that means, except it's patterned >after legacy mapping of device drivers to entries in /dev. Right. The end user shouldn't need to know any of the implementation details. >On the other hand, I'd sympathise with any end user who wouldn't know >how to find the productId of their input device. I'd also sympathise >with any user who doesn't understand/know that his MoronClone 5000 is >supported by the Aiptek driver... Well, there are several steps towards a complete solution, but I think most of them will need some type of input device enumeration in general. At that point, it's a configuration issue to go from the user saying "I want to use the wacom driver and have it drive the first compatible device it finds." to "Load the correct driver for the input devices you find." to "Do whatever is most sensible when you detect a new input device." Finally users want to be able to do runtime configuration type things, and save configuration preferences between sessions. What we have right now with graphics devices is the first stage. I've been doing some work on the first part of the second stage (for graphics devices). >>>Given that we're dealing with hotplug systems, and are now seeing a >>>series of device mappings to pseudo-devices (unlike, say, /dev/tty01, >>>which always refers to a specific serial port), I'm wondering if there >>>should be a different keyword in the Config file to augment "Device"... >>> >>>This is half-baked, so I'm throwing it out for comment for than anything: >>> >>>1. Device /path # same behavior as before >>>2. DeviceDesc >>> Bus "USB" >>> ID "Wacom" >>> EndDeviceDesc >>> >>>The notion here is, something that is matched to the operating system >>>will scan the 'pseudo-mapped' devices, knowing that it's looking for a >>>Wacom device on one of the USB ports. It should come back with an array >>>of paths (in case you have more than one tablet), which the device >>>driver loader then uses as it's path for opening the handle. >> >> >> In the current non-hotplug environment, one approach might be to enumerate >> input devices in a way analogous to what we do with video cards, and >> bind InputDevice sections to hardware with a similar method to that used >> for Device sections. This would at least allow you to say in your >> configuration that you want to use a wacom device, and the driver will >> bind to the "first" one. > >Yes, with one cavaet: you require that the user figures out the BusId >for the card. Fortunately, so far, the card doesn't move from slot to >slot on its own... Only if you have multiple cards, and because you need a mechanism for tying the currently static configuration information to a particular card. In the absence of the user specifying a BusID for the card, the "primary" card is used. That's basically the analogy I mean. >> I've been doing some things to allow the mouse driver to automatically >> find a device without having to be told where to find it. But I'm >> looking at this stuff from the point of view of handling the most common >> user situations now, while working towards a more general solution rather >> than holding everything up until the general solution is worked through. > >So you are looking at a list of likely candidates to see who really has >a mouse connected? (E.g., /dev/psaux, /dev/input/mouse0, /dev/mouse) >That's fair. If you relied on kudzu or discover, you might know exactly >where/what you have. Yes. It's limited by what I currently have available, but it tries to figure out which device to use, and has a fallback for guessing the protocol when the existing auto-detection fails (as it does with the KVM switch I'm using). >Interestingly, in Linux, /proc/bus/input/devices tells us what we'd >like, using key data points the user would know, > >I: Bus=0011 Vendor=0001 Product=0002 Version=ab02 >N: Name="AT Set 2 keyboard" >P: Phys=isa0060/serio0/input0 >H: Handlers=kbd event0 >B: EV=120003 >B: KEY=4 2000000 c061f9 fbc9d621 efdfffdf ffefffff ffffffff fffffffe >B: LED=7 > >I: Bus=0011 Vendor=0002 Product=0001 Version=000b >N: Name="PS/2 Logitech Mouse" >P: Phys=isa0060/serio1/input0 >H: Handlers=mouse0 event1 >B: EV=7 >B: KEY=70000 0 0 0 0 0 0 0 0 >B: REL=3 > >I: Bus=0003 Vendor=08ca Product=0020 Version=0100 >N: Name="Aiptek" >P: Phys=usb-0000:00:1f.4-2/input0 >H: Handlers=kbd mouse1 event3 >B: EV=1f >B: KEY=1c5f 0 70000 0 0 0 ff f000000 ffa0001f f8000000 3 >B: REL=303 >B: ABS=d000103 >B: MSC=1 > >Well, it tells you you have a mouse, but doesn't tell you it's mapped at >/dev/misc/psaux. It mistakenly tells you it's mapped to >/dev/input/mouse0, but truthfully tells you about /dev/input/event1. > >It all dances around the question, so I'll restate it. You know you have >hardware made by vendor 'X', model 'Y'. You may know bus 'Z'. You know >through experience that /dev/somepath is something that's changeable, >because it doesn't refer to a specific hardware interface (e.g., >/dev/tty01, or /dev/usb/2-2:0) but something virtual. Add hotplug to >make it more fun. Do you, > >1. Rig up the XF86Config file so you can optionally describe the >hardware, so that X, armed with an OS-specific extension, finds the >device entry for today/now, or: >2. Well, I suppose there are sed/perl preprocessing I can do on >XF86Config before X starts up. Let's pretend I didn't say that... I think that input drivers should be able to find devices that they're capable of driving. That really means implmenting some form of input device enumeration so that the input drivers can see what devices are potentially available, and then see which of those match up with what the user has requested. How tight the matching is would depend on how tightly the device is specified in the static configuration. It all depends on how quick a solution you need vs how complete a solution you want. For the mouse driver, I've taken the approach of having the os-support level mouse code use OS-specific methods to figure out how to get the mouse if one is connected. The sole reason for going this way is that it should handle the needs of most users now rather than later. You could do something similar with other drivers, but at some point it's better to start making inroads on the more general solution. David -- David Dawes X-Oz Technologies www.XFree86.org/~dawes www.x-oz.com _______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
