Re: XInput: The device type in XListInputDevices comes up again...
Bryan W. Headley writes: Egbert Eich wrote: Bryan W. Headley writes: As opposed to writing it to a log file. However keep in mind that what the X client opts to do with any such message(s) is up to that installation, including logging it to a file. But I'm thinking more along the lines of a) notifying the user with some dialog, or b) passing the message to the help desk through unknown mechanisms. (Email! :-) Sure, the client is free to do whatever it wants. b) send requests to external agents who can do things the X driver cannot. Example: Under Linux HID, you cannot program the HID device from its client API (e.g., no ioctls to switch from relative to absolute coordiantes) But it may be known that the kernel driver DOES support mode switching through other means (the ubiquitous procfs/sysfs) This is ugly. It could be done but then we'd have a linux only driver. If the HID interface would offer such things one could design a generic system interface with a OS dependent and an OS independent part. What I wanted to get across was the notion that the driver COULD initiate a conversation with a client of a very singular nature. Putting that into the API resolves any issues from people subverting other calls for their purposes. Regards generic system interface... we presently have several drivers that support different IO subsystems, and as a consequence are repeating code. Layers that I see are, o Datastream retrieval. E.g., is it RS-232, USB, Linux Input, Firewire? Such a layer needs to know the OS device entry, perhaps information on baud rate, etc. Highly reusable; we're talking about one set of binary per input type; one-to-many state objects (one per open connection) Yes. o Packet building. This would be input device/interface type specific. It would know that a packet of incoming data is 'x' bytes in length; it might understand that bit 4 is always set for synchronization purposes. It composes the hardware's packet into a generic packet, understood by, o Device Driver. The layer that understands that it's receiving input from a Wacom tablet; it's able to convert incoming packets into PostMotion events. Specific to the generic hardware product, but only requires a new packet builder to support a new input interface. I don't know if it is worth the trouble to separate the two latter ones. If I look at mice (which I've worked for recently) I see an opportunity to put in a generic post processing layer between the bare axis and button detection and the PostMotion/Button() call. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Egbert Eich wrote: Bryan W. Headley writes: o Packet building. This would be input device/interface type specific. It would know that a packet of incoming data is 'x' bytes in length; it might understand that bit 4 is always set for synchronization purposes. It composes the hardware's packet into a generic packet, understood by, o Device Driver. The layer that understands that it's receiving input from a Wacom tablet; it's able to convert incoming packets into PostMotion events. Specific to the generic hardware product, but only requires a new packet builder to support a new input interface. I don't know if it is worth the trouble to separate the two latter ones. If I look at mice (which I've worked for recently) I see an opportunity to put in a generic post processing layer between the bare axis and button detection and the PostMotion/Button() call. I saw some input devices that delivered 12-byte packets on RS-232, and 8-byte packets on USB. They were doing things like only using 7 bits, and setting a CRC bit in every byte (effectively giving them 6 bits per byte). But once the data was extracted, the same logic applied regardless of whether RS-232 or USB model. The logic was still manufacturer/model specific. That's why I split the levels... Also! This also deals with the issue of one tablet being one device, potentially feeding events to one-to-many X device drivers. E.g., the hardware abstraction layer now gets the hotplug event; it sends a message to it's packet decoder and X device drivers that input from this device is now suspended. -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Bryan W. Headley writes: Egbert Eich wrote: Bryan W. Headley writes: True, and that's a whole other set of problems. At least, in your example, everything is in the XI layer, if not in the individual driver. I'm more worried about an XI layer that talks to its drivers, but there's also a layer in Misc that does the same thing, but perhaps supercedes the XI layer, but all of that has been replaced by something in a third layer. No, not necessarily. If you take a look at the current xf86misc extensions they implement setting of some mouse parameters. Most of them are clearly related to mouse HW and are well separable form the XI view of things. That just illustrates the problem. Who would think to look at the Misc extension for that? I do. The point is: I'd opt a uniform concept to talk to the hw driver layer for all devices. There are other devices than just input devices. Correnly even the option handling of input drivers is different from graphics drivers. If possible these things should be made uniform. So what would you propose? Duplicate this in another extension or handling output drivers thu XI? Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Egbert Eich wrote: Bryan W. Headley writes: No. I have merged the VIA driver and I did some work on it to fix some issues that violated the driver design guidelines. Cool. 2) How is it going? 3) I notice that Via also has L4V and DRM code for X, too. Do you know if they're putting it into the distribution? Well, Alan Cox is working on getting this going. Thanks. -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Egbert Eich wrote: That just illustrates the problem. Who would think to look at the Misc extension for that? I do. I wouldn't. You could tell me that Misc deals with TrueType fonts and translucense, and I'd have no reason to disbelieve you, until I looked at the headers/docs... The point is: I'd opt a uniform concept to talk to the hw driver layer for all devices. There are other devices than just input devices. Correnly even the option handling of input drivers is different from graphics drivers. If possible these things should be made uniform. Me, too. So what would you propose? Duplicate this in another extension or handling output drivers thu XI? Absolutely not. One communications layer; it deals with all device drivers. This is a fair summary of what I've been talking about all along, 1. It deals with all driver configuration/reconfiguration/querying of configuration. Configuration as defined as that specifiable in your XG86Config file. Also will deal with driver activation/deactivation, in response to an external Hotplug notification facility. 2. Driver state querying/programming. We're talking about the sort of parameters you currently see in the device-specific Misc extension, the XI extension, Even bizarro things like asking the current battery power level can be serviced at this level. 3. I still want drivers to be able to initiate their own messages, a) to report error conditions (battery too low; device unavailable) b) send requests to external agents who can do things the X driver cannot. Example: Under Linux HID, you cannot program the HID device from its client API (e.g., no ioctls to switch from relative to absolute coordiantes) But it may be known that the kernel driver DOES support mode switching through other means (the ubiquitous procfs/sysfs) Numbers 2 and 3 potentially have a pretty open vocabulary, as they are driver type and driver-specific. Number 3 I've been calling QoS all this time, as its primary use is #3a. -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Bryan W. Headley writes: Egbert Eich wrote: A lot of error conditions can only be fixed by the administrator. Can you come up with a really good real life example? I suppose 'Battery Low' would be one. That's the easiest one for everyone to grasp. Let's see: problems with the input device (it didn't accept programming/switch mode commands we asked for). I'm trying to think what would be a less-than-disasterous but still inconvenient situation for a video card to report... OK. That makes sense. However if your protocol supports mode setting you can implement this as the success status reported back. When you were talking about QoS messages I was thinking more of an event-type-of-thing. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Bryan W. Headley writes: True, and that's a whole other set of problems. At least, in your example, everything is in the XI layer, if not in the individual driver. I'm more worried about an XI layer that talks to its drivers, but there's also a layer in Misc that does the same thing, but perhaps supercedes the XI layer, but all of that has been replaced by something in a third layer. No, not necessarily. If you take a look at the current xf86misc extensions they implement setting of some mouse parameters. Most of them are clearly related to mouse HW and are well separable form the XI view of things. How this will turn out in the end is probably not so much a matter of implementation but of discipline and coordination. Yes! But also documentation, both in terms of self-documenting code and the manuals in the ./doc directory. (Because, whoever looks at docs? :-) Right. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Egbert Eich wrote: OT for a second... I've read somewhere that the Xv layer has problems with the VIA CLE266 driver, and that you were working on it. 1) True? (Did you know you were working on it, or is this someone's mistaken impression?) 2) How is it going? 3) I notice that Via also has L4V and DRM code for X, too. Do you know if they're putting it into the distribution? 4) That hardware MPEG-2 decoder of theirs is going to drive everyone nuts. I'm already there... -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Egbert Eich wrote: Bryan W. Headley writes: True, and that's a whole other set of problems. At least, in your example, everything is in the XI layer, if not in the individual driver. I'm more worried about an XI layer that talks to its drivers, but there's also a layer in Misc that does the same thing, but perhaps supercedes the XI layer, but all of that has been replaced by something in a third layer. No, not necessarily. If you take a look at the current xf86misc extensions they implement setting of some mouse parameters. Most of them are clearly related to mouse HW and are well separable form the XI view of things. That just illustrates the problem. Who would think to look at the Misc extension for that? -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Egbert Eich wrote: Bryan W. Headley writes: Egbert Eich wrote: A lot of error conditions can only be fixed by the administrator. Can you come up with a really good real life example? I suppose 'Battery Low' would be one. That's the easiest one for everyone to grasp. Let's see: problems with the input device (it didn't accept programming/switch mode commands we asked for). I'm trying to think what would be a less-than-disasterous but still inconvenient situation for a video card to report... OK. That makes sense. However if your protocol supports mode setting you can implement this as the success status reported back. Failures can occur at any time, not just at the time when a status message is being created. That is why, for QoS messages, the driver is the initiator of the message. (I also agree that status reply messages are good. And would go so far as to suggest that they could be complex, or long messages. E.g., you ask it for its status, and it replies with a message with several Atoms interspersed. Only to differentiate it from an API that only allows the return of an int, or something...) Depending on the contract of the driver, QoS messages can be sent very irregularly (once every unexplained failure, aka, once every battery failure) or perhaps once every heartbeat. That depends on what the driver writer thinks is desirable. -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Egbert Eich wrote: Bryan W. Headley writes: Egbert Eich wrote: 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. Under Linux it is. Under BSD and Solaris (I think), you have read/write to USB devices. But if you do a read() from the device and the syscall errors out, that's an issue the X Driver can report. If the X driver expects relative coordinates but for some reason is receiving absolute coordinates, that's reason to issue a report. Are you sure? We'd have to check why the read would error out. It would do so if the device was closed because it was removed. That's a normal event when a device is hot pluggable. If XI supports removing of devices it would just notify the XClient of the removal. The coordinate issue is a device - driver compatibility problem. Do we want to report this to the client, or is it sufficient to tell the user about the problem in the log file. It *could* be a hotplug issue. But assume it's not: is it worth issuing a message somewhere? You say yes, because you'd put it in a log file somewhere. I agree, but think that giving the message the opportunity to pop up on a driver message monitoring app to be more enterprise friendly. My problem with log files is that they're generally put into a directory only the administrator can read. You've just made the product more expensive to support/maintain... -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
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 CT 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. -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Egbert Eich wrote: I dropped Jim Gettys a note, asking him about his involvement with XInput. If he's not working on it anymore, maybe he can pass some of his ideas and we can incorporate that. And if he is, great. The more the merrier. Right. No reply from Jim yet. Either he's not interested or I got thrown into his junk email filter. Much like your email did -- don't know why. Need a Bayessian debugger to watch it's decision tree... :-) -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Bryan W. Headley writes: Egbert Eich wrote: Bryan W. Headley writes: Egbert Eich wrote: 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. Under Linux it is. Under BSD and Solaris (I think), you have read/write to USB devices. But if you do a read() from the device and the syscall errors out, that's an issue the X Driver can report. If the X driver expects relative coordinates but for some reason is receiving absolute coordinates, that's reason to issue a report. Are you sure? We'd have to check why the read would error out. It would do so if the device was closed because it was removed. That's a normal event when a device is hot pluggable. If XI supports removing of devices it would just notify the XClient of the removal. The coordinate issue is a device - driver compatibility problem. Do we want to report this to the client, or is it sufficient to tell the user about the problem in the log file. It *could* be a hotplug issue. But assume it's not: is it worth issuing a message somewhere? You say yes, because you'd put it in a log file somewhere. I agree, but think that giving the message the opportunity to pop up on a driver message monitoring app to be more enterprise friendly. One could argue that any serious condition that is reported in the log should also get reported by to interested clients. So far XFree86 doesn't know many such events. Most error conditons happen during startup where you have no option but to log them. My problem with log files is that they're generally put into a directory only the administrator can read. You've just made the product more expensive to support/maintain... A lot of error conditions can only be fixed by the administrator. Can you come up with a really good real life example? I suppose 'Battery Low' would be one. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Joe Krahn wrote: 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. Hope I wasn't dancing on anyone's toes So, if all of this will be an XINPUT expansion, this discussion would be better off in the little-used XINPUT list. There is such a list? Where? 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. Atoms, enumerations, outright strings... I'm not too concerned either way, I only advise taking the opportunity to standardize the vocabulary behind the control name fields, lest we get caught in a mire. We're sort of there already, insofar as clients trying to infer too much meaning from existing XINPUT callback structs will get punished. Just because I like to incite riots, if it turns out we send XML messages back and forth, I won't be too hot bothered about it. (Now, duck!) -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Egbert Eich wrote: A lot of error conditions can only be fixed by the administrator. Can you come up with a really good real life example? I suppose 'Battery Low' would be one. That's the easiest one for everyone to grasp. Let's see: problems with the input device (it didn't accept programming/switch mode commands we asked for). I'm trying to think what would be a less-than-disasterous but still inconvenient situation for a video card to report... -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Egbert Eich wrote: Bryan W. Headley writes: 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. The problem is that different layers have different views of things. As we already found out the XI may view every pen of a tablet as a different device while the driver considers the tablet as one device as it communicates with it. I don't want to put things into a specific layer which don't belong into its level of abstraction. True, and that's a whole other set of problems. At least, in your example, everything is in the XI layer, if not in the individual driver. I'm more worried about an XI layer that talks to its drivers, but there's also a layer in Misc that does the same thing, but perhaps supercedes the XI layer, but all of that has been replaced by something in a third layer. How this will turn out in the end is probably not so much a matter of implementation but of discipline and coordination. Yes! But also documentation, both in terms of self-documenting code and the manuals in the ./doc directory. (Because, whoever looks at docs? :-) -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Egbert Eich wrote: 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. Under Linux it is. Under BSD and Solaris (I think), you have read/write to USB devices. But if you do a read() from the device and the syscall errors out, that's an issue the X Driver can report. If the X driver expects relative coordinates but for some reason is receiving absolute coordinates, that's reason to issue a report. And yes, the kernel device driver can also issues quality of service reports. In the kernel's case, there's no-one that you can specifically send reports to. With my kernel device driver, I have a diagnostic file in the procfs that something could monitor for complaints... -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Egbert Eich wrote: Bryan W. Headley writes: Maybe not everything... Some things only make sense at server startup, but yes, I want to make things configurable on the fly - but using another extension, not XI. Correct. My outlook is a more generic client -- driver API (remember I use the word client very loosely -- it could be the parse XF86Config file, tell drivers to load into memory, and configure yourself to XXX client. Because face it, what's unique about an input device that it needs a special status-reporting, state-setting, loading/unloading self to hotplug events API? Well, maybe we should first define the word 'client' so we are sure to talk about the same thing. When I say 'cleint' I mean X client (ie. any application connecting to the server thru the protocol). Your definition and mine are very similar. I would continue the definition to say that even intrinsic server functions, like loading a driver into memory, can be initiated by a client. Why? Because I would want to keep the actual server separate from these ancilliary functions. Maybe I haven't understood what this is good for. Maybe it is just the confusion of terms. Darn! What I offered later in the mail thread you didn't see value in, either. I'll either have to send you to some white papers talking about other products doing QoS, or think of a better example for you... That's a different client than what I'm calling a client. OK, I should call my client an X-client. I don't think this needs to live in it's own thread. You have to open a /dev/something and listen for messages, don't you? No reason to have a separate thread there. 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. 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 CT driver might use a different message?) Let's all get out the USB HID documentation and rip to pieces what's wrong/vague/ill considered in their teminology, then we'll have the beginnings of a wrong/vague etc., language for talking to drivers... OK, you want to start with the HW interface. Ah, no. HID tries to standardize hardware attributes for different devices into common terminology. Then they define standard messages for setting attributes and querying attributes from the hardware, given a standardized language. (Actually, enums) Their specs barely acknowledge that it's running on USB :-) But it's the beginning of figuring out what attributes different types of hardware would have, and creating standardized terms for everything. (I believe) they made a few mistakes, but it's still something to learn from. The XI needs to be entirely independent of this. It must abstract the entire HW if and needs to be generic enough to permit different HW interfaces. In prinicple both should be developed independently by different groups. Otherwise the XI X-client interface will be implemented too much along the OS specific HW interface. Completely agree. The X-client interface should only be concerned with the message format. -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Bryan W. Headley writes: Egbert Eich wrote: Your definition and mine are very similar. I would continue the definition to say that even intrinsic server functions, like loading a driver into memory, can be initiated by a client. Why? Because I would want to keep the actual server separate from these ancilliary functions. This is not how an X client works. X abstracts all these details from the client. The client should not have to deal with HW specific details at all. Certain exceptions to this rule make sense, I agree, but they must be considered carefully. Maybe I haven't understood what this is good for. Maybe it is just the confusion of terms. Darn! What I offered later in the mail thread you didn't see value in, either. I'll either have to send you to some white papers talking about other products doing QoS, or think of a better example for you... I did see the examples later in the message. So far X doesn't send QoS messages to the user. Most of the time these things are expected to be handled by the driver as good as it can. If it cannot handle them the condition is usually fatal anyway. Such things get recorded in the log file as this is something the 'administrator' will have to deal with. When a read returns unexpectedly this usually doesn't point to a problem the user can deal with. If somebody cuts the cable this would either result in a normal unplug event (in case of a USB device) with the result that the client will receive the message that the device has been unregistered or remain unnoticed altogether (serial device). 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. That's a different client than what I'm calling a client. OK, I should call my client an X-client. I don't think this needs to live in it's own thread. You have to open a /dev/something and listen for messages, don't you? No reason to have a separate thread there. 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? 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 CT 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. Let's all get out the USB HID documentation and rip to pieces what's wrong/vague/ill considered in their teminology, then we'll have the beginnings of a wrong/vague etc., language for talking to drivers... OK, you want to start with the HW interface. Ah, no. HID tries to standardize hardware attributes for different devices into common terminology. Then they define standard messages for setting attributes and querying attributes from the hardware, given a standardized language. (Actually, enums) Their specs barely acknowledge that it's running on USB :-) OK. But it's the beginning of figuring out what attributes different types of hardware would have, and creating standardized terms for everything. (I believe) they made a few mistakes, but it's still something to learn from. OK. The XI needs to be entirely independent of this. It must abstract the entire HW if and needs to be generic enough to permit different HW interfaces. In prinicple both should be developed independently by different groups. Otherwise the XI X-client interface will be implemented too much along the OS specific HW interface. Completely agree. The X-client interface should only be concerned with the message format. OK. Cheers, Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Bryan W. Headley writes: Egbert Eich wrote: 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. Under Linux it is. Under BSD and Solaris (I think), you have read/write to USB devices. But if you do a read() from the device and the syscall errors out, that's an issue the X Driver can report. If the X driver expects relative coordinates but for some reason is receiving absolute coordinates, that's reason to issue a report. Are you sure? We'd have to check why the read would error out. It would do so if the device was closed because it was removed. That's a normal event when a device is hot pluggable. If XI supports removing of devices it would just notify the XClient of the removal. The coordinate issue is a device - driver compatibility problem. Do we want to report this to the client, or is it sufficient to tell the user about the problem in the log file. And yes, the kernel device driver can also issues quality of service reports. In the kernel's case, there's no-one that you can specifically send reports to. With my kernel device driver, I have a diagnostic file in the procfs that something could monitor for complaints... Do you have to obtain this information from a dedicated diagnostics file, couldn't you read it from the general kernel log? I do understand QoS notifications where one deals with frequently occuring conditions that require rapid action - like battery low information, but all cases of software of hardware failure are exceptional incidences that would be sufficient to log. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Mike A. Harris writes: Doesn't the following CVS commits implement such an API? Yes, although I don't like the implementation. It requires that the client knows the exact details of a particular driver. This should be replaced by something that provides more information on the particular type of configuration data. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Bryan W. Headley writes: Maybe not everything... Some things only make sense at server startup, but yes, I want to make things configurable on the fly - but using another extension, not XI. Correct. My outlook is a more generic client -- driver API (remember I use the word client very loosely -- it could be the parse XF86Config file, tell drivers to load into memory, and configure yourself to XXX client. Because face it, what's unique about an input device that it needs a special status-reporting, state-setting, loading/unloading self to hotplug events API? Well, maybe we should first define the word 'client' so we are sure to talk about the same thing. When I say 'cleint' I mean X client (ie. any application connecting to the server thru the protocol). 2) a QoS layer, that the driver can use to initiate it's own messages to unknown listeners. I keep losing you on this one. Am I losing you on the concept, or the usefulness? Maybe I haven't understood what this is good for. Maybe it is just the confusion of terms. Yes, that would be a radical change in input driver design. You'd have some dummy agent which knows about the available driver, waits for hotplug messages and just load the appropiate driver. This however is quite independent of the XI extension (apart from generating events that a new device has arrived.) That's correct. A device manager component of the X Server, which I would call a client because it's likely executing in it's own thread, which gets messages from the OS and tells drivers to load/unload theirselves. It also poses a security risk, and now there has to be an understanding over who is sending said messages, and what that person is capable of asking for. That's a different client than what I'm calling a client. OK, I should call my client an X-client. I don't think this needs to live in it's own thread. You have to open a /dev/something and listen for messages, don't you? No reason to have a separate thread there. Not user customizable. But definalbe by each individual driver. Of course. But if you're asking drivers questions without knowing/caring what type of driver it is, you'll need some sort of standard vocabulary. Right. That's what we need a registry for. If we're talking about driver configuration, the drivers DO control what the option names are with impunity. The only reason why there isn't total chaos is because there is a finite number of terms you can call options, and we tend to look at each others' work right. But if there was an API where you can ask standardized questions of any device driver, e.g., what's the resolution along the x-axis, what would be the keyword you use? xResolution? Good, except the number of axes are up to about 7 on input tablets (x, y, z, pen tilt on x y, pen rotation, wheel). And the units of measurement need to be expressed, coming back. A monitor would talk about dot pitch (not neccesarily caring about the resolution it's video card is driving it at); the input device would talk about coordinates per inch/mm. I'm trying to remember what Mickeys meant, in terms of mouse movement... My favorite sick question to ask a video driver is, if you're implementing translucence, what's the simulated Z coordinate's resolution? (And because it's simulated NOW, what makes you think it's uniform across the entire area of display) Let's all get out the USB HID documentation and rip to pieces what's wrong/vague/ill considered in their teminology, then we'll have the beginnings of a wrong/vague etc., language for talking to drivers... :-) OK, you want to start with the HW interface. The XI needs to be entirely independent of this. It must abstract the entire HW if and needs to be generic enough to permit different HW interfaces. In prinicple both should be developed independently by different groups. Otherwise the XI X-client interface will be implemented too much along the OS specific HW interface. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
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
Re: XInput: The device type in XListInputDevices comes up again...
Bryan W. Headley writes: David Dawes wrote: On Fri, Aug 29, 2003 at 02:28:13PM -0400, Joe Krahn wrote: I've discussed XINPUT before, tried to fix some things, and realized that the XFree86 XINPUT code needs a complete re-write. It is particularly messed up for non-pointer devices. Jim Gettys took over XFree86 XINPUT, and agreed that a re-write is needed. I put off working on XINPUT until he got started, because he knows much more about X than me. I've been busy doing other things, so I don't know what the recent progress is in updating XINPUT. As a general rule it's usually not a good idea to use the possibility that someone else might be working on something as a reason to delay starting on it yourself. Unless, that is, you're in the loop with what is happening. I got caught out on this myself regarding functionality simliar to RandR a couple of years ago :-(. No but you don't want to be a jerk and compete with somebody else. As if there were enough developers to go around that we'd steal each other's projects :-) If you know that somebody is interested in this you should get in touch with him. Maybe he can contribute to the discusson but has no time to look at the implementation. If he is even too busy to contribute ideas to the discussion the person may not be able to get to this topic in the near future anyway. I'm not aware of anyone currently working on a rewrite of the X Input extension for XFree86. Now would be a good time for someone who is to speak up. Otherwise the discussions here should continue with the goal of solidifying how a new version of the input extension for XFree86 should look. I dropped Jim Gettys a note, asking him about his involvement with XInput. If he's not working on it anymore, maybe he can pass some of his ideas and we can incorporate that. And if he is, great. The more the merrier. Right. I don't know about taking on the whole layer, but I'm definately going to write a 'feedback' API that's bidirectional and will accept an array of Atoms/values. I still think there's synergy between that and the XF86Config parser. E.g., the same mechanism can deliver XF86OptionRec's, and the xf86findOptionXXX API can be reused on the driver's side. That way, initial driver load/configuration, configuration query, reconfiguration could rely on the same parsing API, and you're no longer exclusively tied to XF86Config files You should abstract yourself more form XF86Config when you do this. I definitely would not use the same parsing API. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Rafa³ Rzepecki writes: On Thursday 28 of August 2003 17:59, Egbert Eich wrote: Sure. What we should probably do now is to get in touch with all interested parties to get their input. We must make sure we don't jump too short again. A generalized API for passing messages to and from the driver (to userspace and back) would be more than useful. It would serve as a way to implement device-specific features, requiring specialized client support without losing the generic features that all the apps could use. In the very early days of [EMAIL PROTECTED] Sven Luther and I discussed something like this. Eventually this discussion faded out in the heat of these days For example I could use this API in communicating battery and RF channel status of my cordless mouse to a client and sending RF channel switching requests. A client-driver communication is neccessary here, because a user would want to know the battery level at any given moment, and also be able to switch the channel whenever xe likes to. Right. Few drivers do such things now, but using weird tricks (vide XLedFeedback in citron or shared memory in synaptics). Yes, many of those 'tricks' may actually introduce security holes. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Claus Matthiesen writes: Actually, I'm really getting into the idea that the device can sort of tell the application how to interpret its data. I'll elaborate later in the mail... OK. You may want to 'bind' one tablet to one application and the other one to another appication. I don't know if this would be any useful. You could use the same stylus on both tablets (if both tablets can use this styles) and then it would appear as a different device. The tablet itself however doesn't have to appear at all - as you said. As I was trying to find some clever way of making a general structure without using a hierachy, I realized that that probably is the easiest, most future-secure way of doing it. Alright, you convinced me. ;-) Yes. But with the wide range of input devices how unified can this be? You can always treat something generically - but you will be missing some of the device dependend features. This is semi-correct. Which means that it's correct unless you're very careful when you design it. But we're being careful, aren't we? Again, I'll elaborate later on the flexible API I'm thinking of later... Hm, I bet when the current XI was designed it was considered flexible, too. Both a connect and disconnect event. When somebody brings in a new pen you want to know about this. Removing a pen is more difficult. This can only happen when the tablet is unhooked. It might be because I'm unfamiliar with X's inner workings but I don't understand those last two sentences... Why is removing a pen more difficult? I may have been imprecise. You can register a pen that hasn't been seen before by bringing it close to the tablet so that the tablet detects it. You cannot remove a pen once it is moved out of the proximity of the tablet. Only if the tablet itself is unhooked (or otherwise unregistered) you must forget all its devices. Joystics? Foreced feedback devices? Non of those have been addressed so far. Everybody seems to be talking directly to the kernel interface. Ah - force feedback! That even requires information to trickle back along the pathfrom the API into the driver and back to the device. Good point. e) Device ID identification. You may want to add properties to a certain pen so that when you use this pen it behaves in a certain way. Therefore you must be able to uniquely identify the pen. Yes! I definitely need that urgently too. Sure. What we should probably do now is to get in touch with all interested parties to get their input. We must make sure we don't jump too short again. Precisely. Who are the interested parties? And why aren't they reading this mailing list - or, is they are, coming with any input? That's a good question. Partly because some still consider this mailing list being focussed on graphics hardware issues? The GUI folks are not very interested in this. There is another mailing list [EMAIL PROTECTED] which was established to communicate with those groups that are building on top of X. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Bryan W. Headley writes: Egbert Eich wrote: Claus Matthiesen writes: Let's just forget about expanding the _XDeviceInfo struct for a minute and just concentrate on the -type field. Because as regards legacy software: Does anybody use the -type field? I don't want to change the -name, that's fine as it is and that's what most people use now as I understand it. It's the -type field that bugs me because the documentation actually says it should return the information I want - it just doesn't. I just seem to remeber that the type field is used in the wrong way by the driver. Some seem to make their own atoms instead of using the predefined ones. Actually, we don't need to re-open the driver as such. If you plug the tablet in again, can't we just pretend it's a brand new tablet and that the old one just died and went away? If we don't look for the tablet but for the pens we may even be able to reidentify the pens by their IDs. Not all tablets support pen IDs but some seem to do. At which point, you might as go the extra steps that MY private API has, which allows the client to change ANY parameter of the device driver that could be specified in the XF86Config file, while the driver is running... ...which is a good thing. We should just make a unified API for it. The problem is that there is no decend way to communicate this information to the server yet. Heh. In my spare time, I'll put something together. But things of value that I'm looking at, 1) A layer that can configure/inspect the driver (e.g., it handles everything in the XF86Config file, bidirectionally). Which fits right into making that puppy modular/enterprise controllable. Maybe not everything... Some things only make sense at server startup, but yes, I want to make things configurable on the fly - but using another extension, not XI. 2) a QoS layer, that the driver can use to initiate it's own messages to unknown listeners. ? 3) An external event interface. Basically your hotplug events, although I'd like to extend that to supporting a conversation like, well, a tablet's now plugged in; you have no tablet drivers loaded now. The tablet's identified by 'blahblahblah'. Figure out which driver that corresponds to, load yourself with default settings Yes, that would be a radical change in input driver design. You'd have some dummy agent which knows about the available driver, waits for hotplug messages and just load the appropiate driver. This however is quite independent of the XI extension (apart from generating events that a new device has arrived.) 4) Then, some level of user-customizable API. E.g., all parameters have names that are converted to Atoms, whose values are type-safely converted back and forth. Gad, it sounds like SOAP / XML/RPC! Maybe it is... Not user customizable. But definalbe by each individual driver. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Egbert Eich wrote: Claus Matthiesen writes: I may have been imprecise. You can register a pen that hasn't been seen before by bringing it close to the tablet so that the tablet detects it. You cannot remove a pen once it is moved out of the proximity of the tablet. Only if the tablet itself is unhooked (or otherwise unregistered) you must forget all its devices. Well, you *could* unload a device driver by moving the pen away from the tablet. I wonder about the usefulness of this, but you could keep a timestamp of the last event read from pen 'x', and if, say, it hasn't sent anything in 5 minutes, it's device driver can issue a request to unload it to some manager. Problem is, 1. Not all styluses have serial numbers, so not all tablets could support this. (But so what; that's why you get the tablet with the most features and the best device drivers...) 2. The driver is only woken up when some input device it has control of sends data. No-one could rely on it accurately knowing when 5 minutes are up. That's a good question. Partly because some still consider this mailing list being focussed on graphics hardware issues? The GUI folks are not very interested in this. There is another mailing list [EMAIL PROTECTED] which was established to communicate with those groups that are building on top of X. They should be, because I'll next start talking about hot-plugging monitors, something which does happen in server rooms. And before any of you ask why an admin would run X locally on a server in the server room, consider the Win32 admin, who thinks it natural to have a login screen on every one of his machines. They are out there... -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Egbert Eich wrote: Bryan W. Headley writes: Egbert Eich wrote: Claus Matthiesen writes: Let's just forget about expanding the _XDeviceInfo struct for a minute and just concentrate on the -type field. Because as regards legacy software: Does anybody use the -type field? I don't want to change the -name, that's fine as it is and that's what most people use now as I understand it. It's the -type field that bugs me because the documentation actually says it should return the information I want - it just doesn't. I just seem to remeber that the type field is used in the wrong way by the driver. Some seem to make their own atoms instead of using the predefined ones. Actually, we don't need to re-open the driver as such. If you plug the tablet in again, can't we just pretend it's a brand new tablet and that the old one just died and went away? If we don't look for the tablet but for the pens we may even be able to reidentify the pens by their IDs. Not all tablets support pen IDs but some seem to do. At which point, you might as go the extra steps that MY private API has, which allows the client to change ANY parameter of the device driver that could be specified in the XF86Config file, while the driver is running... ...which is a good thing. We should just make a unified API for it. The problem is that there is no decend way to communicate this information to the server yet. Heh. In my spare time, I'll put something together. But things of value that I'm looking at, 1) A layer that can configure/inspect the driver (e.g., it handles everything in the XF86Config file, bidirectionally). Which fits right into making that puppy modular/enterprise controllable. Maybe not everything... Some things only make sense at server startup, but yes, I want to make things configurable on the fly - but using another extension, not XI. Correct. My outlook is a more generic client -- driver API (remember I use the word client very loosely -- it could be the parse XF86Config file, tell drivers to load into memory, and configure yourself to XXX client. Because face it, what's unique about an input device that it needs a special status-reporting, state-setting, loading/unloading self to hotplug events API? 2) a QoS layer, that the driver can use to initiate it's own messages to unknown listeners. I keep losing you on this one. Am I losing you on the concept, or the usefulness? 3) An external event interface. Basically your hotplug events, although I'd like to extend that to supporting a conversation like, well, a tablet's now plugged in; you have no tablet drivers loaded now. The tablet's identified by 'blahblahblah'. Figure out which driver that corresponds to, load yourself with default settings Yes, that would be a radical change in input driver design. You'd have some dummy agent which knows about the available driver, waits for hotplug messages and just load the appropiate driver. This however is quite independent of the XI extension (apart from generating events that a new device has arrived.) That's correct. A device manager component of the X Server, which I would call a client because it's likely executing in it's own thread, which gets messages from the OS and tells drivers to load/unload theirselves. It also poses a security risk, and now there has to be an understanding over who is sending said messages, and what that person is capable of asking for. 4) Then, some level of user-customizable API. E.g., all parameters have names that are converted to Atoms, whose values are type-safely converted back and forth. Gad, it sounds like SOAP / XML/RPC! Maybe it is... Not user customizable. But definalbe by each individual driver. Of course. But if you're asking drivers questions without knowing/caring what type of driver it is, you'll need some sort of standard vocabulary. If we're talking about driver configuration, the drivers DO control what the option names are with impunity. The only reason why there isn't total chaos is because there is a finite number of terms you can call options, and we tend to look at each others' work But if there was an API where you can ask standardized questions of any device driver, e.g., what's the resolution along the x-axis, what would be the keyword you use? xResolution? Good, except the number of axes are up to about 7 on input tablets (x, y, z, pen tilt on x y, pen rotation, wheel). And the units of measurement need to be expressed, coming back. A monitor would talk about dot pitch (not neccesarily caring about the resolution it's video card is driving it at); the input device would talk about coordinates per inch/mm. I'm trying to remember what Mickeys meant, in terms of mouse movement... My favorite sick question to ask a video driver is, if you're implementing
Re: XInput: The device type in XListInputDevices comes up again...
Egbert Eich wrote: Few drivers do such things now, but using weird tricks (vide XLedFeedback in citron or shared memory in synaptics). Yes, many of those 'tricks' may actually introduce security holes. You bet they do! But I also agree that a user should be able to ask his stylus it's battery level, if it's capable of reporting that information. Hell, I'd like the driver to send a Quality Of Service message on it's own if the battery level is less than a given theshold (Go get a new battery please) The only way to mitigate the risk is to an API capable of such messages, and then have a single point of failure to architect around. -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Mike A. Harris wrote: On Sun, 31 Aug 2003, Egbert Eich wrote: On Thursday 28 of August 2003 17:59, Egbert Eich wrote: Sure. What we should probably do now is to get in touch with all interested parties to get their input. We must make sure we don't jump too short again. A generalized API for passing messages to and from the driver (to userspace and back) would be more than useful. It would serve as a way to implement device-specific features, requiring specialized client support without losing the generic features that all the apps could use. In the very early days of [EMAIL PROTECTED] Sven Luther and I discussed something like this. Eventually this discussion faded out in the heat of these days Doesn't the following CVS commits implement such an API? No, but it is the beginning of one. Right now, you cannot specify the device driver you want to talk to; you specify the Display and screen. But it certainly can be generalized, so any device driver can receive/reply to messages. -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
In the very early days of [EMAIL PROTECTED] Sven Luther and I discussed something like this. Eventually this discussion faded out in the heat of these days Doesn't the following CVS commits implement such an API? No, but it is the beginning of one. Right now, you cannot specify the device driver you want to talk to; you specify the Display and screen. But it certainly can be generalized, so any device driver can receive/reply to messages. Ok, I see what's perceived as missing now. Yeah, that would be useful functionality. TTYL -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Bryan W. Headley wrote: No but you don't want to be a jerk and compete with somebody else. As if there were enough developers to go around that we'd steal each other's projects :-) Sometimes a little competition can improve the final product. Think lvm2 v. evms in the early 2.5 kernels. Warren -- Treasurer, GOLUM, Inc. http://www.golum.org ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Warren Turkal wrote: Bryan W. Headley wrote: No but you don't want to be a jerk and compete with somebody else. As if there were enough developers to go around that we'd steal each other's projects :-) Sometimes a little competition can improve the final product. Think lvm2 v. evms in the early 2.5 kernels. At least they knew about each other, but I take your point. -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
I've discussed XINPUT before, tried to fix some things, and realized that the XFree86 XINPUT code needs a complete re-write. It is particularly messed up for non-pointer devices. Jim Gettys took over XFree86 XINPUT, and agreed that a re-write is needed. I put off working on XINPUT until he got started, because he knows much more about X than me. I've been busy doing other things, so I don't know what the recent progress is in updating XINPUT. First, most of the XINPUT protocol isn't too bad, although it is rather simplistic - designed before input devices were smart. Expanding it seems the best approach to me. Problems that would need some changes that are not completely backwards compatible are: 1) Device Controls must be expandable. This means types should be Atoms, not an int enumerator. Since Atoms and ints are the same size, and it is highly unlikely for an Atom to conflict with a single-digit enum, it would allow binary compatibility. 2) Also for device control expandability, control data structures need to be generic char/word/int data, as in XClient message. Since the structures are variable-length unions, this is still compatible with Xlib calls, but needs a server protocol update. 3) Some commands that have global scope should be handled separately for each device connection, such as XSetDeviceMode sending relative or absolute data. A few other comments: The current protocol is also not incompatible with device hot-plugging. We probably need to fit in well with HID. Even though HID is not so great, it is a widely used standard. Device controls should follow Config file semantics. Joe Krahn Rafa Rzepecki wrote: On Thursday 28 of August 2003 17:59, Egbert Eich wrote: Sure. What we should probably do now is to get in touch with all interested parties to get their input. We must make sure we don't jump too short again. A generalized API for passing messages to and from the driver (to userspace and back) would be more than useful. It would serve as a way to implement device-specific features, requiring specialized client support without losing the generic features that all the apps could use. For example I could use this API in communicating battery and RF channel status of my cordless mouse to a client and sending RF channel switching requests. A client-driver communication is neccessary here, because a user would want to know the battery level at any given moment, and also be able to switch the channel whenever xe likes to. Few drivers do such things now, but using weird tricks (vide XLedFeedback in citron or shared memory in synaptics). ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
--- Bryan W. Headley [EMAIL PROTECTED] a écrit : Egbert Eich wrote: Bryan W. Headley writes: snip 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. The identification could be done by several attempts : -First try should perhaps be done via the X config file. This method would overrid any other one because in last resort the user knows what he bought. This could be done just by a match between whatever information identifying the device returned by the kernel on plug event (called device ID from now on) (The user won't know about it the first time, but I'll explain how to fix that below. -Second try : no sections matches the device ID. No problem let lookup a table like the kernel one (should be possible to have ambiguities here). If we find it and there is no ambiguity we're done else... -Third try : if we don't find it or there were ambiguities, just ask the user telling him: Device ... has been plugged, tell me what it is among this list. And this can be added to the config file so that next time the first try will work. Perhaps one of the problem of that approach is : if the user booted up with all things alredy plugged in how do we get all the devices IDs we need? Moreover the lookup table and the parser can be quite hairy but in a first try we can just do something really simplistic, and complicate that after (this would be more user friendly as X would be smarter and would not bother the user because he did not recognize her device) Bye Manu ___ Do You Yahoo!? -- Une adresse @yahoo.fr gratuite et en français ! Yahoo! Mail : http://fr.mail.yahoo.com ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
On Fri, Aug 29, 2003 at 02:28:13PM -0400, Joe Krahn wrote: I've discussed XINPUT before, tried to fix some things, and realized that the XFree86 XINPUT code needs a complete re-write. It is particularly messed up for non-pointer devices. Jim Gettys took over XFree86 XINPUT, and agreed that a re-write is needed. I put off working on XINPUT until he got started, because he knows much more about X than me. I've been busy doing other things, so I don't know what the recent progress is in updating XINPUT. As a general rule it's usually not a good idea to use the possibility that someone else might be working on something as a reason to delay starting on it yourself. Unless, that is, you're in the loop with what is happening. I got caught out on this myself regarding functionality simliar to RandR a couple of years ago :-(. I'm not aware of anyone currently working on a rewrite of the X Input extension for XFree86. Now would be a good time for someone who is to speak up. Otherwise the discussions here should continue with the goal of solidifying how a new version of the input extension for XFree86 should look. David -- David Dawes Founder/committer/developer The XFree86 Project www.XFree86.org/~dawes ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Claus Matthiesen writes: Exactly. Sort of guessing on the basis of a string which might contain this or that isn't good enough for industrial strength software which we all agree should be able to run under Linux/XFree. But unless I am much mistaken, there is *no other* way of finding out which kind of device one's got ones hands on - please correct me if I'm wrong, because that's what I need... Unfortunately no. What we probably need is a Registry for known devices. However the naming sceme needs to be generic enough to also hold enough information so that if a device is not known to an application that the application can do something useful with it. you make an Atom, call it XI_STYLUS, etc., and mess you up, because you'd hardly be expected to know that a XI_STYLUS is related to a tablet But do you really need to know that? Isn't it enough to know it's a stylus? If you've got two tablets (which after all must be a bit rare) do you care, either from the applications or the users point of view, which tablet is used with which stylus? (I am here ignoring the fact that the stylae must physically work with the tablets of course) As far as I understand it (without being an expert on tablets) the fact that there's a tablet is rather uninteresting. You may want to 'bind' one tablet to one application and the other one to another appication. I don't know if this would be any useful. You could use the same stylus on both tablets (if both tablets can use this styles) and then it would appear as a different device. The tablet itself however doesn't have to appear at all - as you said. (that's sort of localized knowledge to the given device being supported). The term 'tablet' is inconclusive. XI_TABLET should not be used for such tablets. I can argue both for and against that statement. Don't forget, the application using the API possibly will want to indicate the pen device #1, #2 and mouse device #3 are all related to a tablet, in the spirit of user-friendliness. ...and if that's really useful knowledge, what you're saying is that we need some sort of grouping of devices. Well, I can go along with that... Or a hirachy. Input devices are a rather wide area. I have difficulties to overlook what all may be required, but when we extend the XInput extension we must be careful not to impose limits like the old one did. The tablet itself is not really the device as far as XI is concerned. It does not provide coordinates/keys/buttons itself. Yes it is but no it isn't. Remember, there is a single cable running from the tablet to the USB port. Which means, if it's hotplug disabled, somebody has to understand that all these devices should be disabled... But if stylus, cursor and eraser are all registered as unique devices, won't that just mean that for every registered device we get a message that it's been unplugged? It can't be a problem to disable all the devices which are plugged into the tablet within X itself when the tablet is unplugged or switched off and then X just needs to tell me as an application programmer that each of these devices - the stylus, eraser, etc. - have been disabled... Yes. Ideally, shouldn't the _XDeviceInfo struct contain some sort of information about how to decode the information in the events one receives from the device? It's certainly not very elegant if it's necessary to have the program explicitly know which tablet the driver is running. The whole point of a driver is to have a unified interface. If there's something this interface can't express then it's a problem with the interface and it must be changed or expanded. Yes. But with the wide range of input devices how unified can this be? You can always treat something generically - but you will be missing some of the device dependend features. These would be properties. Properties can be accumulated, types are exclusive. I don't know if we can manage to characterize all device properties completely and if this is desirable. In many cases we may just be able to supply coordinates and the application needs to be configured to know what to do with these. A heirarchical system is the way to go. Well - isn't that an overkill? So far the only thing that's come up as a problem is a tablet and that has only one level of hierachy which is even a bit contorted since the highest level in the hierachy - the tablet - doesn't produce events while the lower level - stylus, eraser, etc. - does. It may or may not be. Input devices are not tablets only. Summation: a) Can't every device attached to a tablet just become an independent device in X, so that one can ask for an XI_CURSOR, XI_STYLUS or XI_ERASER? We might expand the _XDeviceInfo struct to contain information about grouping if that's desired. This could be implemented quite
Re: XInput: The device type in XListInputDevices comes up again...
Claus Matthiesen writes: Let's just forget about expanding the _XDeviceInfo struct for a minute and just concentrate on the -type field. Because as regards legacy software: Does anybody use the -type field? I don't want to change the -name, that's fine as it is and that's what most people use now as I understand it. It's the -type field that bugs me because the documentation actually says it should return the information I want - it just doesn't. I just seem to remeber that the type field is used in the wrong way by the driver. Some seem to make their own atoms instead of using the predefined ones. Actually, we don't need to re-open the driver as such. If you plug the tablet in again, can't we just pretend it's a brand new tablet and that the old one just died and went away? If we don't look for the tablet but for the pens we may even be able to reidentify the pens by their IDs. Not all tablets support pen IDs but some seem to do. At which point, you might as go the extra steps that MY private API has, which allows the client to change ANY parameter of the device driver that could be specified in the XF86Config file, while the driver is running... ...which is a good thing. We should just make a unified API for it. The problem is that there is no decend way to communicate this information to the server yet. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Egbert Eich wrote: Let me finish by saying that even though I have never had my hands deep in the code of X, of course I'd be happy to help out - if doing a little coding in X makes my port of the toolkit go smoother it's definetely worth the effort. All I need to have is a consensus on what we want. Sure. What we should probably do now is to get in touch with all interested parties to get their input. We must make sure we don't jump too short again. What I want to see is a unified system to configuring the input device. For example, under Linux USB/HID, you're not going to send a sequence to the tablet to switch between relative and absolute coordinates. Unless of course you also wrote the kernel device driver and somehow know how. Which I did and I do, but I've been known to cheat :-) -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Egbert Eich wrote: Claus Matthiesen writes: Let's just forget about expanding the _XDeviceInfo struct for a minute and just concentrate on the -type field. Because as regards legacy software: Does anybody use the -type field? I don't want to change the -name, that's fine as it is and that's what most people use now as I understand it. It's the -type field that bugs me because the documentation actually says it should return the information I want - it just doesn't. I just seem to remeber that the type field is used in the wrong way by the driver. Some seem to make their own atoms instead of using the predefined ones. Actually, we don't need to re-open the driver as such. If you plug the tablet in again, can't we just pretend it's a brand new tablet and that the old one just died and went away? If we don't look for the tablet but for the pens we may even be able to reidentify the pens by their IDs. Not all tablets support pen IDs but some seem to do. At which point, you might as go the extra steps that MY private API has, which allows the client to change ANY parameter of the device driver that could be specified in the XF86Config file, while the driver is running... ...which is a good thing. We should just make a unified API for it. The problem is that there is no decend way to communicate this information to the server yet. Heh. In my spare time, I'll put something together. But things of value that I'm looking at, 1) A layer that can configure/inspect the driver (e.g., it handles everything in the XF86Config file, bidirectionally). Which fits right into making that puppy modular/enterprise controllable. 2) a QoS layer, that the driver can use to initiate it's own messages to unknown listeners. 3) An external event interface. Basically your hotplug events, although I'd like to extend that to supporting a conversation like, well, a tablet's now plugged in; you have no tablet drivers loaded now. The tablet's identified by 'blahblahblah'. Figure out which driver that corresponds to, load yourself with default settings 4) Then, some level of user-customizable API. E.g., all parameters have names that are converted to Atoms, whose values are type-safely converted back and forth. Gad, it sounds like SOAP / XML/RPC! Maybe it is... -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
On Thu, 2003-08-28 at 17:59, Egbert Eich wrote: Claus Matthiesen writes: Exactly. Sort of guessing on the basis of a string which might contain this or that isn't good enough for industrial strength software which we all agree should be able to run under Linux/XFree. But unless I am much mistaken, there is *no other* way of finding out which kind of device one's got ones hands on - please correct me if I'm wrong, because that's what I need... Unfortunately no. What we probably need is a Registry for known devices. However the naming sceme needs to be generic enough to also hold enough information so that if a device is not known to an application that the application can do something useful with it Actually, I'm really getting into the idea that the device can sort of tell the application how to interpret its data. I'll elaborate later in the mail... you make an Atom, call it XI_STYLUS, etc., and mess you up, because you'd hardly be expected to know that a XI_STYLUS is related to a tablet But do you really need to know that? Isn't it enough to know it's a stylus? If you've got two tablets (which after all must be a bit rare) do you care, either from the applications or the users point of view, which tablet is used with which stylus? (I am here ignoring the fact that the stylae must physically work with the tablets of course) As far as I understand it (without being an expert on tablets) the fact that there's a tablet is rather uninteresting. You may want to 'bind' one tablet to one application and the other one to another appication. I don't know if this would be any useful. You could use the same stylus on both tablets (if both tablets can use this styles) and then it would appear as a different device. The tablet itself however doesn't have to appear at all - as you said. As I was trying to find some clever way of making a general structure without using a hierachy, I realized that that probably is the easiest, most future-secure way of doing it. Alright, you convinced me. (that's sort of localized knowledge to the given device being supported). The term 'tablet' is inconclusive. XI_TABLET should not be used for such tablets. I can argue both for and against that statement. Don't forget, the application using the API possibly will want to indicate the pen device #1, #2 and mouse device #3 are all related to a tablet, in the spirit of user-friendliness. ...and if that's really useful knowledge, what you're saying is that we need some sort of grouping of devices. Well, I can go along with that... Or a hirachy. Input devices are a rather wide area. I have difficulties to overlook what all may be required, but when we extend the XInput extension we must be careful not to impose limits like the old one did. Yes, yes! You already swayed me! :-) But if stylus, cursor and eraser are all registered as unique devices, won't that just mean that for every registered device we get a message that it's been unplugged? It can't be a problem to disable all the devices which are plugged into the tablet within X itself when the tablet is unplugged or switched off and then X just needs to tell me as an application programmer that each of these devices - the stylus, eraser, etc. - have been disabled... Yes. Ideally, shouldn't the _XDeviceInfo struct contain some sort of information about how to decode the information in the events one receives from the device? It's certainly not very elegant if it's necessary to have the program explicitly know which tablet the driver is running. The whole point of a driver is to have a unified interface. If there's something this interface can't express then it's a problem with the interface and it must be changed or expanded. Yes. But with the wide range of input devices how unified can this be? You can always treat something generically - but you will be missing some of the device dependend features. This is semi-correct. Which means that it's correct unless you're very careful when you design it. But we're being careful, aren't we? Again, I'll elaborate later on the flexible API I'm thinking of later... Well - isn't that an overkill? So far the only thing that's come up as a problem is a tablet and that has only one level of hierachy which is even a bit contorted since the highest level in the hierachy - the tablet - doesn't produce events while the lower level - stylus, eraser, etc. - does. It may or may not be. Input devices are not tablets only. Yes, yes! A hierachy! OK! :-) Summation: a) Can't every device attached to a tablet just become an independent device in X, so that one can ask for an XI_CURSOR, XI_STYLUS or XI_ERASER? We might expand the _XDeviceInfo struct to contain information about grouping if that's desired.
Re: XInput: The device type in XListInputDevices comes up again...
- Original Message - From: Bryan W. Headley [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, August 26, 2003 9:43 PM Subject: Re: XInput: The device type in XListInputDevices comes up again... Cut a bit of code The problem is, there's a type field and a name field. They're not populated consistently by all drivers, and the fields are not sufficient to accurately describe the device, anyway. That is correct. However Claus was talking about the future - once that is fixed. Appearantly toolkits like gnome already do make use of the name field. Sure, albeit dangerously. They had best not be making decisions based on what's returned in the string... Exactly. Sort of guessing on the basis of a string which might contain this or that isn't good enough for industrial strength software which we all agree should be able to run under Linux/XFree. But unless I am much mistaken, there is *no other* way of finding out which kind of device one's got ones hands on - please correct me if I'm wrong, because that's what I need... you make an Atom, call it XI_STYLUS, etc., and mess you up, because you'd hardly be expected to know that a XI_STYLUS is related to a tablet But do you really need to know that? Isn't it enough to know it's a stylus? If you've got two tablets (which after all must be a bit rare) do you care, either from the applications or the users point of view, which tablet is used with which stylus? (I am here ignoring the fact that the stylae must physically work with the tablets of course) As far as I understand it (without being an expert on tablets) the fact that there's a tablet is rather uninteresting. (that's sort of localized knowledge to the given device being supported). The term 'tablet' is inconclusive. XI_TABLET should not be used for such tablets. I can argue both for and against that statement. Don't forget, the application using the API possibly will want to indicate the pen device #1, #2 and mouse device #3 are all related to a tablet, in the spirit of user-friendliness. ...and if that's really useful knowledge, what you're saying is that we need some sort of grouping of devices. Well, I can go along with that... The tablet itself is not really the device as far as XI is concerned. It does not provide coordinates/keys/buttons itself. Yes it is but no it isn't. Remember, there is a single cable running from the tablet to the USB port. Which means, if it's hotplug disabled, somebody has to understand that all these devices should be disabled... But if stylus, cursor and eraser are all registered as unique devices, won't that just mean that for every registered device we get a message that it's been unplugged? It can't be a problem to disable all the devices which are plugged into the tablet within X itself when the tablet is unplugged or switched off and then X just needs to tell me as an application programmer that each of these devices - the stylus, eraser, etc. - have been disabled... What I'd like, but haven't started an in-depth search for in the API: given a deviceInfo struct, I'd like to learn the device driver name associated with the device. The device driver is completely irrelevant to the application. Why should the application know that? The application may want to know a vendor string and an ID to know more about the properties of an individual device (some pens supply pressure or angular data some don't). Most do not. Mine does, because it's the client side of that client/driver API I mentioned: it has to know which drivers support my extended API. But I don't expect to find that kind of info in the deviceInfo struct... Ideally, shouldn't the _XDeviceInfo struct contain some sort of information about how to decode the information in the events one receives from the device? It's certainly not very elegant if it's necessary to have the program explicitly know which tablet the driver is running. The whole point of a driver is to have a unified interface. If there's something this interface can't express then it's a problem with the interface and it must be changed or expanded. These would be properties. Properties can be accumulated, types are exclusive. I don't know if we can manage to characterize all device properties completely and if this is desirable. In many cases we may just be able to supply coordinates and the application needs to be configured to know what to do with these. A heirarchical system is the way to go. Well - isn't that an overkill? So far the only thing that's come up as a problem is a tablet and that has only one level of hierachy which is even a bit contorted since the highest level in the hierachy - the tablet - doesn't produce events while the lower level - stylus, eraser, etc. - does. Summation: a) Can't every device attached to a tablet just become an independent device in X, so that one can ask for an XI_CURSOR, XI_STYLUS
Re: XInput: The device type in XListInputDevices comes up again...
Bryan W. Headley writes: Egbert Eich wrote: That is correct. However Claus was talking about the future - once that is fixed. Appearantly toolkits like gnome already do make use of the name field. Sure, albeit dangerously. They had best not be making decisions based on what's returned in the string... Yes, to some extend. The app would have to know the exact string used in the driver. Let's talk about tablets: tablets CAN support separate pointers concurrently. On the wacom and my aiptek driver, you can have a cursor, a stylus and an eraser. They are mapped into individual XFree devices, pseudo-devices, because they all share the same file descriptor (of course they do: all inputs come in from the same OS device). Now, if you want to relate that this device is somehow a tablet, you set type to XI_TABLET (but you loose the ability to easily determine if the inputs from a cursor, stylus, eraser.) So, if you decide that's more important, you make an Atom, call it XI_STYLUS, etc., and mess you up, because you'd hardly be expected to know that a XI_STYLUS is related to a tablet (that's sort of localized knowledge to the given device being supported). The term 'tablet' is inconclusive. XI_TABLET should not be used for such tablets. I can argue both for and against that statement. Don't forget, the application using the API possibly will want to indicate the pen device #1, #2 and mouse device #3 are all related to a tablet, in the spirit of user-friendliness. Right. If we want that we'd need some kind of device hirachy. The tablet itself is not really the device as far as XI is concerned. It does not provide coordinates/keys/buttons itself. Yes it is but no it isn't. Remember, there is a single cable running from the tablet to the USB port. Which means, if it's hotplug disabled, somebody has to understand that all these devices should be disabled... Right, the driver knows and can mark all devices (ie. styluses etc) that depend on this cable as disabled. The application has a different view on things than the driver has. Most do not. Mine does, because it's the client side of that client/driver API I mentioned: it has to know which drivers support my extended API. But I don't expect to find that kind of info in the deviceInfo struct... Right. There are simply too many possibilities. So you'd have to teach the client which valuator, axis, key, or button does what. These would be properties. Properties can be accumulated, types are exclusive. I don't know if we can manage to characterize all device properties completely and if this is desirable. In many cases we may just be able to supply coordinates and the application needs to be configured to know what to do with these. A heirarchical system is the way to go. Are you talking about a hirachy for the devices or for the device properties? Yes, I also came to the conclusion that we may need a device hirachy. Egbert. ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Claus Matthiesen wrote: - Original Message - From: Bryan W. Headley [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, August 26, 2003 9:43 PM Subject: Re: XInput: The device type in XListInputDevices comes up again... Cut a bit of code The problem is, there's a type field and a name field. They're not populated consistently by all drivers, and the fields are not sufficient to accurately describe the device, anyway. That is correct. However Claus was talking about the future - once that is fixed. Appearantly toolkits like gnome already do make use of the name field. Sure, albeit dangerously. They had best not be making decisions based on what's returned in the string... Exactly. Sort of guessing on the basis of a string which might contain this or that isn't good enough for industrial strength software which we all agree should be able to run under Linux/XFree. But unless I am much mistaken, there is *no other* way of finding out which kind of device one's got ones hands on - please correct me if I'm wrong, because that's what I need... Well, if you are doing a switch/case on the Atom, this infers very strongly that you know upfront what every Atom could be for your decision tree. But if you don't care, you convert the Atom to a char*, display it, and maybe the string's meaning is implicit to the viewer... What will drive you insane is that tablet device driver X likes names like 'Stylus', and Y likes to put the name of a manufacturer, but Z prefers putting the names of fruits (and of course, I prefer putting the driver's identifier, so it matches the XF86Config file). You'll go insane keeping track of my weirdness versus the fruit guy's... you make an Atom, call it XI_STYLUS, etc., and mess you up, because you'd hardly be expected to know that a XI_STYLUS is related to a tablet But do you really need to know that? Isn't it enough to know it's a stylus? If you've got two tablets (which after all must be a bit rare) do you care, either from the applications or the users point of view, which tablet is used with which stylus? (I am here ignoring the fact that the stylae must physically work with the tablets of course) As far as I understand it (without being an expert on tablets) the fact that there's a tablet is rather uninteresting. Yes, I do. In a hotplug situation, where the tablet is unplugged while the server is running, I'm going to be told by the kernel that tablet-x is gone. I have to understand that this means either disabling or passivating the device drivers for stylus-y, cursor-z, and eraser-a. Actually, it's worse than that: the kernel neither knows nor cares that the device mapped to pci:00/:00:1f.4/usb2/2-1/2-1:0 was a tablet of type XI_TABLET. If I'm lucky, it might think to pass the USB vendorID and productID which would tell me that it's an Aiptek 8000U (but then I have to establish the relationship of that with XI_TABLET with the name of... what? (I prefer pci:00/:00:1f.4/usb2/2-1/2-1:0) Associated with file descriptor 'x'... Who is being used in a select() call by several X input drivers that I now need to passivate or perhaps remove entirely from memory. 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... (that's sort of localized knowledge to the given device being supported). The term 'tablet' is inconclusive. XI_TABLET should not be used for such tablets. I can argue both for and against that statement. Don't forget, the application using the API possibly will want to indicate the pen device #1, #2 and mouse device #3 are all related to a tablet, in the spirit of user-friendliness. ...and if that's really useful knowledge, what you're saying is that we need some sort of grouping of devices. Well, I can go along with that... The tablet itself is not really the device as far as XI is concerned. It does not provide coordinates/keys/buttons itself. Yes it is but no it isn't. Remember, there is a single cable running from the tablet to the USB port. Which means, if it's hotplug disabled, somebody has to understand that all these devices should be disabled... But if stylus, cursor and eraser are all registered as unique devices, won't that just mean that for every registered device we get a message that it's been unplugged? It can't be a problem to disable all the devices which are plugged into the tablet within X itself when the tablet is unplugged or switched off and then X just needs to tell me as an application programmer that each
Re: XInput: The device type in XListInputDevices comes up again...
Weee! Device interface designing is fun! As a side note - isn't it rater a failure of the extended input thingy in X when neither the application programmer nor the device driver programmer think it's good enough? On Wed, 2003-08-27 at 17:03, Bryan W. Headley wrote: Claus Matthiesen wrote: - Original Message - From: Bryan W. Headley [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, August 26, 2003 9:43 PM Subject: Re: XInput: The device type in XListInputDevices comes up again... Cut a bit of code The problem is, there's a type field and a name field. They're not populated consistently by all drivers, and the fields are not sufficient to accurately describe the device, anyway. That is correct. However Claus was talking about the future - once that is fixed. Appearantly toolkits like gnome already do make use of the name field. Sure, albeit dangerously. They had best not be making decisions based on what's returned in the string... Exactly. Sort of guessing on the basis of a string which might contain this or that isn't good enough for industrial strength software which we all agree should be able to run under Linux/XFree. But unless I am much mistaken, there is *no other* way of finding out which kind of device one's got ones hands on - please correct me if I'm wrong, because that's what I need... Well, if you are doing a switch/case on the Atom, this infers very strongly that you know upfront what every Atom could be for your decision tree. But if you don't care, you convert the Atom to a char*, display it, and maybe the string's meaning is implicit to the viewer... In detail, what I want to do is this: I'm programming this toolkit in C++. I've created a nifty little classes for the kinds of devices I pretend to know anything about - which for now are keyboards, mice and tablets, with spaceballs and datagloves as a likely addition. When I go through the device list I get from XListInputDevices, I want to map one of these classes to all the devices I know how to handle, ignore the others and so get a list of objects representing every device I know how to deal with. And that's not easy when there's no safe way to classify each device... I'm almost embarrased to say so, but under Windows XP and its new RawInput library, everything works fine... :-) What will drive you insane is that tablet device driver X likes names like 'Stylus', and Y likes to put the name of a manufacturer, but Z prefers putting the names of fruits (and of course, I prefer putting the driver's identifier, so it matches the XF86Config file). You'll go insane keeping track of my weirdness versus the fruit guy's... Exactly. But that's not a reason to give up, that's just a reason to make a standard and make Mr. X, Y and Ms. Z follow it. But I see your point - the way it is now, there's no way to do what I need. you make an Atom, call it XI_STYLUS, etc., and mess you up, because you'd hardly be expected to know that a XI_STYLUS is related to a tablet But do you really need to know that? Isn't it enough to know it's a stylus? If you've got two tablets (which after all must be a bit rare) do you care, either from the applications or the users point of view, which tablet is used with which stylus? (I am here ignoring the fact that the stylae must physically work with the tablets of course) As far as I understand it (without being an expert on tablets) the fact that there's a tablet is rather uninteresting. Yes, I do. In a hotplug situation, where the tablet is unplugged while the server is running, I'm going to be told by the kernel that tablet-x is gone. I have to understand that this means either disabling or passivating the device drivers for stylus-y, cursor-z, and eraser-a. Hmmm... I think the problem is this: I, as an application programmer, do not need to know that all these tablet devices are tied to one tablet; you, as a device driver programmer do need to know. I am aware that behind the X extension layer, it's very much necessary to know that these devices are on a tablet. Otherwise it would be impossible to let me know when the devices tied to the tablet have become unplugged. Actually, it's worse than that: the kernel neither knows nor cares that the device mapped to pci:00/:00:1f.4/usb2/2-1/2-1:0 was a tablet of type XI_TABLET. If I'm lucky, it might think to pass the USB vendorID and productID which would tell me that it's an Aiptek 8000U (but then I have to establish the relationship of that with XI_TABLET with the name of... what? (I prefer pci:00/:00:1f.4/usb2/2-1/2-1:0) Associated with file descriptor 'x'... Who is being used in a select() call by several X input drivers that I now need to passivate or perhaps remove entirely from memory. And just because I'm into fun, let me advise you that /dev/input/event2, which might be the device
Re: XInput: The device type in XListInputDevices comes up again...
Claus Matthiesen wrote: Weee! Device interface designing is fun! As a side note - isn't it rater a failure of the extended input thingy in X when neither the application programmer nor the device driver programmer think it's good enough? La la la la. I can't read you :-) -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
On Wed, 2003-08-27 at 19:52, Bryan W. Headley wrote: Claus Matthiesen wrote: Weee! Device interface designing is fun! As a side note - isn't it rater a failure of the extended input thingy in X when neither the application programmer nor the device driver programmer think it's good enough? La la la la. I can't read you :-) Ahem... eh... I mean of course, *at the time* it might have appeared the way to go... :-) ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
XInput: The device type in XListInputDevices comes up again...
First of all: Since I am new to this list (this is my first post), I do
hope that I'll be able to avoid the major pitfalls of what is considered
bad behaviour on this particular mailing list... :-)
Since I am currently writing a device manager for a cross-platform
windowing toolkit under OpenGL and right now working on the X port of the
toolkit, the behaviour of the device management is very important to me.
On the 26th of June, Egbert Eich concluded a discussion on the fact that
the type and name field of the _XDeviceInfo struct returned by
XListInputDevices contain information which is inconsistent with what the
documentation says by writing (in Re: XInput: device name in
XListInputDevices):
Maybe this is the time to table all issues [with current extended input
management] we can come up with so we can find solutions.
In the meantime I will modify the input drivers to return the id's
predefined types in the type field and the product names in the
'name' field.
As far as I can see, this discussion on the behaviour of the extended
input devices promptly died. I don't really mind if it works the way
Egbert wants to make it work because it would then neatly cover what I
need for my toolkit port - I would say, however, that the current extended
device management as a whole seems rather unsophisticated.
What *is* important, though, is that the -type field of the _XDeviceInfo
struct is made to contain something usable. As I understand it, Egbert
wants to make the -type field contain an atom so that the following
quasi-code would make sense:
{
_XDeviceInfo* device_list = XListInputDevices(display, n);
if (device_list[a].type == XInternAtom(display, XI_TABLET, true))
{
printf(Device %s is a tablet, device_list[a].name);
}
}
Now I have two questions:
a) Should a device's type be tested in the above way once the fix Egbert
suggested has been implemented? I do hope so since it makes the most
sense...
b) When can we expect this fix to have been implemented? Is there already
a patch for it or will it surface in some distant full release of the X11?
Thanks in advance,
Claus Matthiesen
PS.
Egberts original full conclusion can be found at:
http://www.mail-archive.com/[EMAIL PROTECTED]/msg01879.html
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
[EMAIL PROTECTED] wrote:
{
_XDeviceInfo* device_list = XListInputDevices(display, n);
if (device_list[a].type == XInternAtom(display, XI_TABLET, true))
{
printf(Device %s is a tablet, device_list[a].name);
}
}
Now I have two questions:
a) Should a device's type be tested in the above way once the fix Egbert
suggested has been implemented? I do hope so since it makes the most
sense...
No.
The problem is, there's a type field and a name field. They're not
populated consistently by all drivers, and the fields are not sufficient
to accurately describe the device, anyway.
Let's talk about tablets: tablets CAN support separate pointers
concurrently. On the wacom and my aiptek driver, you can have a cursor,
a stylus and an eraser. They are mapped into individual XFree devices,
pseudo-devices, because they all share the same file descriptor (of
course they do: all inputs come in from the same OS device). Now, if you
want to relate that this device is somehow a tablet, you set type to
XI_TABLET (but you loose the ability to easily determine if the inputs
from a cursor, stylus, eraser.) So, if you decide that's more important,
you make an Atom, call it XI_STYLUS, etc., and mess you up, because
you'd hardly be expected to know that a XI_STYLUS is related to a tablet
(that's sort of localized knowledge to the given device being supported).
Now, you have the name field. What do you put in there? Lots of people
put in the name of the device driver. E.g., aiptek or wacom stylus.
This doesn't help the USER, because that's not the identifier he used in
the XF86Config file.
Now, I personally have reasons for wanting to know that a given device
is supported by my device driver: I have a client/driver API layered on
top of the FeedbackControl API. What do I do? Assume because I support a
tablet, that all tablet's found are obviously controlled by my driver
(wrong!) Assume that if I find a XI_CURSOR, it's obviously something
that belongs to my driver? (wrong! the user could have two tablets, one
of which is a wacom...) Do something to the name field to pass three
pieces of information? (e.g., you used the identifier Leopold for the
stylus pseudo device driver, that's controlled by the aiptek driver, so
perhaps Leopod (aiptek:cursor)? That's not real user-friendly. Does
that mean that your app should know to only display the first word of
the name field? Ugh...
What I'd like, but haven't started an in-depth search for in the API:
given a deviceInfo struct, I'd like to learn the device driver name
associated with the device.
What I think is needed, but I don't know if this is sufficient: a device
type and sub-type, which are both Atoms and codified so a user app
actually has a chance of understanding what the string sequence means.
But is a single sub-type sufficient? I don't know. For example, Data
Gloves: is it important to know that it's left or right-handed? Can
those have styluses, too? Then that's two sub-types. Is it possible to
have more?
--
.:.
Bryan W. Headley - [EMAIL PROTECTED]
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Bryan W. Headley writes:
[EMAIL PROTECTED] wrote:
{
_XDeviceInfo* device_list = XListInputDevices(display, n);
if (device_list[a].type == XInternAtom(display, XI_TABLET, true))
{
printf(Device %s is a tablet, device_list[a].name);
}
}
Now I have two questions:
a) Should a device's type be tested in the above way once the fix Egbert
suggested has been implemented? I do hope so since it makes the most
sense...
No.
The problem is, there's a type field and a name field. They're not
populated consistently by all drivers, and the fields are not sufficient
to accurately describe the device, anyway.
That is correct. However Claus was talking about the future - once
that is fixed. Appearantly toolkits like gnome already do make use
of the name field.
Let's talk about tablets: tablets CAN support separate pointers
concurrently. On the wacom and my aiptek driver, you can have a cursor,
a stylus and an eraser. They are mapped into individual XFree devices,
pseudo-devices, because they all share the same file descriptor (of
course they do: all inputs come in from the same OS device). Now, if you
want to relate that this device is somehow a tablet, you set type to
XI_TABLET (but you loose the ability to easily determine if the inputs
from a cursor, stylus, eraser.) So, if you decide that's more important,
you make an Atom, call it XI_STYLUS, etc., and mess you up, because
you'd hardly be expected to know that a XI_STYLUS is related to a tablet
(that's sort of localized knowledge to the given device being supported).
The term 'tablet' is inconclusive. XI_TABLET should not be used for such
tablets. The tablet itself is not really the device as far as XI is
concerned. It does not provide coordinates/keys/buttons itself. That
would be like saying your mousepad is your input device. Instead each
pen should be considered a different input device and we may need to
extend the list of predefined types to accomodate those.
I don't really know if it is at all importand that different pens are
related to a specific tablet. If it is we need a way to 'group'
certain devices together.
Now, you have the name field. What do you put in there? Lots of people
put in the name of the device driver. E.g., aiptek or wacom stylus.
This doesn't help the USER, because that's not the identifier he used in
the XF86Config file.
Now, I personally have reasons for wanting to know that a given device
is supported by my device driver: I have a client/driver API layered on
top of the FeedbackControl API. What do I do? Assume because I support a
tablet, that all tablet's found are obviously controlled by my driver
(wrong!) Assume that if I find a XI_CURSOR, it's obviously something
that belongs to my driver? (wrong! the user could have two tablets, one
of which is a wacom...) Do something to the name field to pass three
pieces of information? (e.g., you used the identifier Leopold for the
stylus pseudo device driver, that's controlled by the aiptek driver, so
perhaps Leopod (aiptek:cursor)? That's not real user-friendly. Does
that mean that your app should know to only display the first word of
the name field? Ugh...
What I'd like, but haven't started an in-depth search for in the API:
given a deviceInfo struct, I'd like to learn the device driver name
associated with the device.
The device driver is completely irrelevant to the application.
Why should the application know that? The application may want
to know a vendor string and an ID to know more about the properties
of an individual device (some pens supply pressure or angular data
some don't).
What I think is needed, but I don't know if this is sufficient: a device
type and sub-type, which are both Atoms and codified so a user app
actually has a chance of understanding what the string sequence means.
But is a single sub-type sufficient? I don't know. For example, Data
Gloves: is it important to know that it's left or right-handed? Can
those have styluses, too? Then that's two sub-types. Is it possible to
have more?
These would be properties. Properties can be accumulated, types are
exclusive. I don't know if we can manage to characterize all device
properties completely and if this is desirable. In many cases we may
just be able to supply coordinates and the application needs to be
configured to know what to do with these.
Egbert.
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
Re: XInput: The device type in XListInputDevices comes up again...
Egbert Eich wrote:
Bryan W. Headley writes:
[EMAIL PROTECTED] wrote:
{
_XDeviceInfo* device_list = XListInputDevices(display, n);
if (device_list[a].type == XInternAtom(display, XI_TABLET, true))
{
printf(Device %s is a tablet, device_list[a].name);
}
}
Now I have two questions:
a) Should a device's type be tested in the above way once the fix Egbert
suggested has been implemented? I do hope so since it makes the most
sense...
No.
The problem is, there's a type field and a name field. They're not
populated consistently by all drivers, and the fields are not sufficient
to accurately describe the device, anyway.
That is correct. However Claus was talking about the future - once
that is fixed. Appearantly toolkits like gnome already do make use
of the name field.
Sure, albeit dangerously. They had best not be making decisions based on
what's returned in the string...
Let's talk about tablets: tablets CAN support separate pointers
concurrently. On the wacom and my aiptek driver, you can have a cursor,
a stylus and an eraser. They are mapped into individual XFree devices,
pseudo-devices, because they all share the same file descriptor (of
course they do: all inputs come in from the same OS device). Now, if you
want to relate that this device is somehow a tablet, you set type to
XI_TABLET (but you loose the ability to easily determine if the inputs
from a cursor, stylus, eraser.) So, if you decide that's more important,
you make an Atom, call it XI_STYLUS, etc., and mess you up, because
you'd hardly be expected to know that a XI_STYLUS is related to a tablet
(that's sort of localized knowledge to the given device being supported).
The term 'tablet' is inconclusive. XI_TABLET should not be used for such
tablets.
I can argue both for and against that statement. Don't forget, the
application using the API possibly will want to indicate the pen device
#1, #2 and mouse device #3 are all related to a tablet, in the spirit of
user-friendliness.
The tablet itself is not really the device as far as XI is
concerned. It does not provide coordinates/keys/buttons itself.
Yes it is but no it isn't. Remember, there is a single cable running
from the tablet to the USB port. Which means, if it's hotplug disabled,
somebody has to understand that all these devices should be disabled...
What I'd like, but haven't started an in-depth search for in the API:
given a deviceInfo struct, I'd like to learn the device driver name
associated with the device.
The device driver is completely irrelevant to the application.
Why should the application know that? The application may want
to know a vendor string and an ID to know more about the properties
of an individual device (some pens supply pressure or angular data
some don't).
Most do not. Mine does, because it's the client side of that
client/driver API I mentioned: it has to know which drivers support my
extended API. But I don't expect to find that kind of info in the
deviceInfo struct...
These would be properties. Properties can be accumulated, types are
exclusive. I don't know if we can manage to characterize all device
properties completely and if this is desirable. In many cases we may
just be able to supply coordinates and the application needs to be
configured to know what to do with these.
A heirarchical system is the way to go.
--
.:.
Bryan W. Headley - [EMAIL PROTECTED]
___
Devel mailing list
[EMAIL PROTECTED]
http://XFree86.Org/mailman/listinfo/devel
