I agree that device messages should all be in one place. There are messages to and from the user, as well as to and from the device.
Early on, one question was should we use XINPUT? Although the name doesn't exactly fit, XINPUT is basically set up for both device and human I/O, and just needs a few important changes to be generalizable.
So, if all of this will be an XINPUT expansion, this discussion would be better off in the little-used XINPUT list.
As for control type names, Atoms make a lot of sense, because they readily expandable, unlike integer enumerators as used in HID. It also seems to me that the current Atom managing code would be a reasonable place to create some sort of registry.
Joe Krahn
Bryan W. Headley wrote:
Egbert Eich wrote:
Bryan W. Headley writes: I do understand the 'the battery in the cordless mouse is getting low' message. This would better live in the hardware messaging, ie. the successor of todays xf86misc extension.
Ah! You're concerned about which layer supports the messaging. I'm not as concerned with that, as I am that the facility exists. Although, the more we put similar functionalities into different layers, the harder it is for a developer to be aware of all of them. For example, a communication layer between the client and the driver should not be in the both the input layer and the misc layer, it should be in a single layer (somewhere) and be capable of communicating with all drivers.
> Don't forget, the same select() loop also receives X events and you > don't want the server to appear sluggish while dealing with non-core > events. So yeah, spawning a thread to deal with them is not a bad idea.
>
How much traffic do you expect?
I don't expect much at all. But I don't want to detract from X's core message dispatch functionality...
> > > > Right. That's what we need a registry for.
> > I think your registry would know how to identify hardware and determine > the correct drivers to load.
> > But are you also suggesting that it knows how to ask the NVidia driver > for its video resolution (e.g., it prefers a message in string format > like, "reso?", whereas the C&T driver might use a different message?)
That's why we need a registry. And I don't like string messages
either. This is the current ad hoc implementiaton.
You are at the point in time where a cohesive attribute <-> token dictionary could be defined and the drivers standardized to understand them in messages. In a world of anarchy, a termcap-like dictionary is appropriate.
_______________________________________________ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
