Bryan W. Headley writes:
> Sorry, just telling you how it is, now. hotplug listens to a kernel
> message layer, and invokes shell scripts in response to events. These
> scripts can load/unload kernel device drivers, mount discs, etc. All
> these things would do is write a message to some kind of listener in X.
> Said listener would be an application...
>
> Architecting it any other way would put us very close to the Linux
> kernel and hard to abstract to other operating system implementations. I
> come from a messaging middleware background, so I'd prefer some kind of
> messaging API that clients who have interest would listen to, and
> receive plug/unplug messages. But Linux hotplug can't do it that way,
> because the components it deals with only understand command line
> invocation and reinvocation (e.g., insmod is a command line utility, not
> a daemon)
>
> What makes hotplug interesting (both in a good and bad way) is that it
> has a flat file database of USB productId/vendorIds and the driver(s) to
> load. The kernel also has a list of devices, more along the lines of
> "these devices have quirks, and the normal algorithm for determining
> which device driver to assign to the hardware won't work... let
> individual drivers ''grab'' these devices, if they are found".
> Department of redundency department... :-)
>
> Knowing that the device has a USB id and using that on our side to keep
> a database of XFree drivers is a little shortsighted; for example, I
> don't know what USB will be replaced with next year, and what it'll use
> for it's identification. Also, with the Aiptek tablets, there happen to
> be 6 separate IDs that match to the kernel driver, as well as several
> clones. So the id becomes something like, "Aiptek-like", or "Wacom-like".
>
> > >
> > > And just because I'm into fun, let me advise you that /dev/input/event2,
> > > which might be the device that the tablet's currently mapped to, is
> > > highly changeable. In other words, the tablet may be event2 today, but
> > > under the same configuration, the kernel decides to map it to event1
> > > tomorrow. And if I plug/unplug the tablet, all bets are off. Why is
> > > that? Because the Linux Input system creates pseudo driver entries:
> > > these names have no correlation to the actual connector the physical
> > > device is connected to, e.g., /dev/tty02...
> >
> > Yes, that's a different issue which can happen to you with usb mice
> > and keyboards, too. This needs to be addressed.
>
> The point is, the device driver 'mount point' (/dev/whatever) no longer
> uniquely identifies a device. I wonder about it's continued exclusive
> use in XF86Config. I further wonder what the best replacement should be...
>
> >
> > > 1) the current struct layouts are pretty restrictive.
> > > 2) I'd like to query an individual driver for it's feedback.
> > > 3) I'd like for a driver to be capable of initiating a conversation. For
> > > example, to send quality-of-service messages ("hey! I keep erroring out
> > > on this select() call -- has the device been unplugged again?!?")
> >
> > The purpose of the XI extension was an abstraction of all that from
> > the client.
> > We learn that such an abstraction is not always possible - that some
> > HW features should be configurable while the server is running.
> > The question is if this should be done thru the XI extension or
> > thru another extension (a revised form of the xf86misc extension)
> > which exposes the driver's view of devices rather than the logical
> > view of the XI extension.
> > I don't quite understand what you are referring to in 3).
> > The driver is free to do any conversation with the HW (or kernel IFs)
> > it requires. This conversation should be abstracted away from the
> > client, though.
>
> No, it isn't. The Linux Input device layer is unidirectional: you listen
> to the tablet, and that's it. There are some ioctl calls you can make to
> determine the OEM name of the input device, and read capacities, but
> that's it.
>
> But that's not what I was referring to, anyway. QoS, or quality of
> service, allows the system to send heartbeat messages, or panic messages
> when things go awry. A message monitor collates these messages and acts
> on them. For example, a read() from the device fails; the XFree driver
> sends a QoS message saying "hey!"; a pop-up appears asking the user if
> they've cut the wire to their mouse...
>
As you said a HID device is more or less unidirectional. Therefore
you won't be able to detect from the device interface that something
is wrong. The HID interface itself would have to provide QoS.
Anyway QoS would not be part of XI but would be implemented in the
HW messaging extension.
Egbert.
_______________________________________________
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
