On Tue, Sep 30, 2003 at 12:51:55PM -0500, Bryan W. Headley wrote:There probably should be, semantics-wise, but there's nothing vis-a-vis the "hotplug" binary. In the sense you are talking of, theoretically, every piece of hardware discovered by their drivers is a hotplug event (regardless of whether they were physically plugged in the entire time or not)
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.
Right. The end user shouldn't need to know any of the implementation details.
Well, I got zapped again this AM. The driver which yesterday was happily mapped to /dev/input/event1, moved over to event2. What I could do is (cheapie kludge),
Option "Device" "/dev/input/event*"
Option "HardwareVendor" "AIPTEK"Then do a glob for all 'event' devices, do an ioctl on each, see who is connected to something made by AIPTEK, and rest there. Which isn't right (because Aiptek could also make mice or touchscreens or there are two tablets) but is a quick hack.
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.
The Hal library can do some of this (your manifest of available 'iron'). But then you'd have to have a registry, matching available XFree drivers to the iron it finds. E.g., PCI IDs for video cards, USB vendorId/ productId... This could be a header within each driver.
It all depends on how quick a solution you need vs how complete a solution you want.
My problem is, I can (easily) be drawn into a quick hack that isn't inline with what you had in mind, both near-term and long-term. E.g., the above 'glob' hack.
-- ____ .:. ____ Bryan W. Headley - [EMAIL PROTECTED]
_______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
