Re: Help: gdb xfree86 video card driver on rh9
harry wrote: Using gdb-xfreemod 6.0 instead of gdb-xfreemod 5.11-2.0 , I could use gdb to debug XFree86 430 under redhat 9.0. Just curious: any reason why the xfree mods to gdb haven't been merged upstream? A religious issue, maybe? -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: 4.3.99.16 aiptek problems
Kambo Lohan wrote: 1. aiptek not working in absolute mode I used evtest /dev/input/event2 and verified I am getting absolute x,y, and reset messages. (not sure what a reset message is) however the cursor is still relative in x (i.e. unusable) even though the Xserverlog says absolute, and it's configed absolute. I am using 2.6.0 test9 with its aiptek driver. If the driver believes the server is in relative mode, it'll convert the absolute coordinates into relative coordinate reports. Come over to aiptektablet.sf.net for Aiptek tablet support. -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Starting XFree86 without an XF86Config file
Sottek, Matthew J wrote: What are you doing now? I assume this is a real product; what are you putting into the XF86Config file now? It was a hypothetical example. I don't know of a decent way to do it with XF86Config short of 256*3 Options. It's 3 curves of 256 datapoints. Floating point or integer. What you have to assume is that every point on the curve is grabbable, either through a spline curve widget, or something like datapoint [123]^ red [ 45] green [ 23] blue [ 52] With the premise being, you scroll to whichever element you want with the datapoint wheel widget; the values for red/green/blue are actually what you'd call red[123], green[123] blue[123] (only because in the example above, we're at the 123rd element) Data storage isn't really the issue. I could write a tool to write those options to the config file but unless every driver wants to receive its gamma data in that format it would be a device specific tool wouldn't it? They who don't like it write a widget and a new metadata tag, and merge it back into the source. Then it supports what they want, and now you can leverage that widget if you want, and everyone can go back to making the value proposition the hardware. Cross-platform? As in Windows and X? I never mentioned that. Not cross OS. Cross hardware platform... as in device independent. Aka, X. which we are, and it is... Nobody does it now... that is the point. When building a GUI that will only generate working configurations for Multi-display you would have to know a lot about the hardware and probably communicate with the driver. That means the code behind the GUI is device specific. Yes, you the hardware vendor have to know a lot. You have to send me meta-data that describes what widgets need to be put on a panel. Their type, whether they take integer or floats, and some field identifier. The program I'm think of will render the panel, query the driver for data, allow user configuration, and allow the data to be passed back to the driver. Take a look at glade: it uses an XML format to describe the widgets and their layout. There's a library, libglade, that loads renders the widgets. All you have to do is plug in the callbacks. The whole thing can be done in an interpretive manner. Look at that and imagine that being the meta-data the driver is asked to produce... Wow, I've haven't seen such total FUD-mongering in a long time. Here, O vendor: if something doesn't meet your needs, you enhance it and give it back to the open source community. New widgets, new metadata... whatever it takes. What are you talking about here? You should read yourself. This is all so hard that really the only one even capable of writing blah blah blah is ourselves... C'mon. There's no brain surgery being done here. My suggestion was simply that you are likely to find configuration options that, for whatever reason, do not fit cleanly into your driver independent GUI. If you ever do think of something, once again, WRITE the given widget in question, IMPLEMENT the meta data, and SEND the patch in. And then the tool will support displaying/soliciting user input for whatever type of data you come up with. In the meantime, you have a flat file that can represent strings, enums and integrals. As far as I know, it supports whatever your driver needs from it. Maybe not in the most sexiest way, but it's a start... If every configuration parameter could be defined in a device independent manner, every driver in Xfree would use the same set of Option lines in XF86Config for the same purpose. Metadata tells me what widgets to render; metadata tells the front-end what option parameters you understand/support. There are two (at least) ways to get the config data stored: 1) Have a setuid root config tool that writes out the XF86Config file. Then have a method for X to re-read the config file and reconfigure itself at runtime. That's the hard way. It's no different than running vi/emacs now... 2) Have wire protocol for altering configuration on the fly. Then have the X server write the data to the XF86Config file. Number 2 is what I've been talking about all along. And that's writing at socket IO level to something that's running as root. THAT has to be audited to make sure there's no exploits. That's why I'd rather there only be one such program to audit. It's interesting how when I was just discussing an idea, I now feel pushed into the corner of writing the damned thing just to show everyone that the simple is indeed possible. Fortunately, there's the crowd demanding separate Gnome/KDE versions, so I can opt out due to users' obvious insanity. Either that or make dynamic widget stuff like Glade work with Athena (which is even more insane) flame Seriously, if somebody replaced Athena with Gtk or Qt or Fox or ___, who'd be upset? /flame -- .:. Bryan W. Headley - [EMAIL PROTECTED
Re: help : Touch screen driver
Mayur Thakare wrote: dt: 03/oct hi everybody, i am a final year student of computer engineering, as part of curriculam i am developing a driver of touch screen in linux. But even after mind blogging hours of interpreting data on com port i failed to recognise exactly what data come on port (touch screen, for which i am developing driver, is connected to com port, this is an external touch screen) can any one give me hint of exactly what data comes on port from touch screen. I will be really greatful to you. Beats me. X, Y, and pressure data? Have you talked to the hardware vendor? Have you captured incoming data from the com port to a file and tried to analyze it? Have you looked at the existing touch screen drivers in X for ideas? -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Starting XFree86 without an XF86Config file
Tim Roberts wrote: On Fri, 03 Oct 2003 15:55:47 -0500, Bryan W. Headley wrote: It's 3 curves of 256 datapoints. Floating point or integer. What you have to assume is that every point on the curve is grabbable, either through a spline curve widget, or something like datapoint [123]^ red [ 45] green [ 23] blue [ 52] With the premise being, you scroll to whichever element you want with the datapoint wheel widget; the values for red/green/blue are actually what you'd call red[123], green[123] blue[123] (only because in the example above, we're at the 123rd element) This discussion needs an infusion of reality. I fully realize there are many graphics cards for which the color curves can be set exactly as you describe, as 3 arrays of 256 elements. The S3 Savages do it that way. However, the UI you describe is just silly. There is NO real-world reason to have a configuration widget that allows gamma setting on a point-by-point basis. For gamma, a single exponent (perhaps one exponent per primary) is the only thing that a UI needs to provide. Probably the most you want to do is introduce a slope to the curve of datapoints. Your single exponent, factored over some formulae. Fortunately for all, I don't write video drivers... -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XF86Config-4 parser
David Dawes wrote: On Tue, Sep 30, 2003 at 12:51:55PM -0500, Bryan W. Headley wrote: David Dawes wrote: On Mon, Sep 29, 2003 at 09:52:16AM -0500, Bryan W. Headley wrote: David, How is the work on the XF86Config parser coming? I ask because I noticed that the 'Option Device /dev/input/event?' is getting weird, like I thought it would when we were discussing Input System improvements. Specifically, my tablet seems to have chosen for it different /dev/input/event? paths where it is mapped to during boot-up. For several times, it's mapped to /dev/input/event2, then after a subsequent reboot, it moves to /dev/input/event1 for awhile... In the short term, can whatever daemon on Linux handles plug events be configured to point some symlink to the correct device? If so, you could refer to that in the XF86Config file? I said nothing about plug events... the tablet was there during bootup. The pseudo /dev entry chosen for the input device ichanges/i, depending on I dunno what. But we both know the hotplug environment adds to this fun. I was assuming that there would be an implicit plug event at boot time. I'm guessing based on how I've seen other systems work. I haven't had an opportunity to play with this stuff on recent Linux kernels yet. There probably should be, semantics-wise, but there's nothing vis-a-vis the hotplug binary. In the sense you are talking of, theoretically, every piece of hardware discovered by their drivers is a hotplug event (regardless of whether they were physically plugged in the entire time or not) Right. The end user shouldn't need to know any of the implementation details. Well, I got zapped again this AM. The driver which yesterday was happily mapped to /dev/input/event1, moved over to event2. What I could do is (cheapie kludge), Option Device /dev/input/event* Option HardwareVendor AIPTEK Then do a glob for all 'event' devices, do an ioctl on each, see who is connected to something made by AIPTEK, and rest there. Which isn't right (because Aiptek could also make mice or touchscreens or there are two tablets) but is a quick hack. Well, there are several steps towards a complete solution, but I think most of them will need some type of input device enumeration in general. At that point, it's a configuration issue to go from the user saying I want to use the wacom driver and have it drive the first compatible device it finds. to Load the correct driver for the input devices you find. to Do whatever is most sensible when you detect a new input device. Finally users want to be able to do runtime configuration type things, and save configuration preferences between sessions. The Hal library can do some of this (your manifest of available 'iron'). But then you'd have to have a registry, matching available XFree drivers to the iron it finds. E.g., PCI IDs for video cards, USB vendorId/ productId... This could be a header within each driver. It all depends on how quick a solution you need vs how complete a solution you want. My problem is, I can (easily) be drawn into a quick hack that isn't inline with what you had in mind, both near-term and long-term. E.g., the above 'glob' hack. -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Starting XFree86 without an XF86Config file
Sottek, Matthew J wrote: The thing is, a unified device-configuring front-end would be better than having every driver writer roll their own. (I mean, we can follow Windows if we want, but why incur development risk by developing what essentially is several versions of the same thing?) Windows does it the way it does for a reason (the Advanced button on the display prefs GUI) You will never be able to create a GUI that covers everything that is configurable across a wide variety of vendor products... nor should you try. Not true. Look at the limited vocabulary you presently have in XF86Config: keywords, list-of-values, integers, bools. Bools map to radio buttons, integers can have spin buttons, list of values are combos. Where's the problem? That the unified code doesn't know what parameters each driver support? That's the purpose of the metadata, so the driver can tell it. You're thinking of Window-dom: because the vendors HAVE to write something, they'd rather write something that distinguishes their product over another vendor. Improves the user experience. Puts up logos, and help screens, and shadowed widgets and whatever... If a vendor legimately thinks of a new/better way to describe a certain parameter, I'm more apt to accept a patch from them to implement new metadata/widgets than I'd want to see another binary on the system that can talk to/configure devices on my X system. Now, as to anyone who say, eww, it's Gtk, or it's Qt, or I hate Tk, I have only one thing to say to them: Athena Widgets. I would advocate a config system that has a basic set of well known parameters. Width, Height, Depth ... maybe muti-display details too. And everything else is left up to the Vendor to implement in their own config program. Same danger. You are writing to someone who's running as root (X). Big security concern. The less often you do it (e.g., one binary instead of every vendor rolling their own binaries) the more you can concentrate on making sure that binary is secure in terms of exploits. -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Starting XFree86 without an XF86Config file
Sottek, Matthew J wrote: You will never be able to create a GUI that covers everything that is configurable across a wide variety of vendor products... nor should you try. Not true. Look at the limited vocabulary you presently have in XF86Config: keywords, list-of-values, integers, bools. Bools map to radio buttons, integers can have spin buttons, list of values are combos. Where's the problem? That the unified code doesn't know what parameters each driver support? That's the purpose of the metadata, so the driver can tell it. Your example proves that you can use standard data types to convey the information. No argument there... but that wasn't the problem. The problem is providing a usable configuration tool. Yes you could map all the standard types to radio buttons, list boxes, etc without knowledge of their function and provide a good driver independent way to access the functionality, but in my opinion that isn't really a usable solution. Just as providing 100 options in the XF86Config file is possible, but not desired. I'll use a couple real world options that would prove hard to map onto a driver independent GUI in any usable manner. Gamma: Intel hardware can gamma control the output using independent 256 point mapping for each of red, green, and blue. You could have a very nice GUI with independent spline curves that could be point and click edited to generate the 256 points. The data would then just be 256*3 integers. What are you doing now? I assume this is a real product; what are you putting into the XF86Config file now? (Walking off, firing up glade-2. Hmm, it's got a widget called Gamma curve. And another one called Curve. That might not be enough; you really want a spline curve where the user specifies which of the 256 points they really want to set individually and the others which are interpolated.) Your cross platform GUI would provide 256*3 sliders and put 256*3 entries in the config file. Cross-platform? As in Windows and X? I never mentioned that. Multi-display: There are two multi-display concepts that XFree understands. Different example, same response: what do you do now? Anyone who is willing is welcome to tackle the problem. Try to build a complete GUI that satisfies all the configuration requirements. Maybe you will get closer than anyone did before, that would be great. However, in the eventuality that you discover something that just needs to be different for different hardware, I suggest you leave it alone and let a vendor specific GUI handle it rather than implement it in a way that doesn't meet anyone's needs. The more you can handle in the cross device GUI the better, but it doesn't eliminate the need and desire for vender specific additions. Wow, I've haven't seen such total FUD-mongering in a long time. Here, O vendor: if something doesn't meet your needs, you enhance it and give it back to the open source community. New widgets, new metadata... whatever it takes. Same danger. You are writing to someone who's running as root (X). Big security concern. The less often you do it (e.g., one binary instead of every vendor rolling their own binaries) the more you can concentrate on making sure that binary is secure in terms of exploits. It is a danger, but don't let existing XFree design characteristics prevent the user from having a good experience. Agreed. If you use the standard data types you were discussing above you can leave all the reading/writing to X. X gets 1000 data types that it knows nothing about and sends them to the driver. When the driver has verified them/applied them it can notify XFree to save them off to a file. It isn't hard to make that secure. Web servers are supposed to be secure, too. And sendmail. But people keep finding all those darned root exploits... Anyway, we can all audit one program or try to audit (hmm, how many hardware vendors' products work with X?) num programs. -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XF86Config-4 parser
David Dawes wrote: On Mon, Sep 29, 2003 at 09:52:16AM -0500, Bryan W. Headley wrote: David, How is the work on the XF86Config parser coming? I ask because I noticed that the 'Option Device /dev/input/event?' is getting weird, like I thought it would when we were discussing Input System improvements. Specifically, my tablet seems to have chosen for it different /dev/input/event? paths where it is mapped to during boot-up. For several times, it's mapped to /dev/input/event2, then after a subsequent reboot, it moves to /dev/input/event1 for awhile... In the short term, can whatever daemon on Linux handles plug events be configured to point some symlink to the correct device? If so, you could refer to that in the XF86Config file? I said nothing about plug events... the tablet was there during bootup. The pseudo /dev entry chosen for the input device ichanges/i, depending on I dunno what. But we both know the hotplug environment adds to this fun. What you would like to see, I think, is, /dev/input/event2 - /somepath/hardware-mapping/usb/wacom/0x1234/1 (Where, I know it's a USB tablet; the tablet knows it's a wacom with a productId of 0x1234, and that this is the first tablet). At which point, I'd argue against the /dev/input/event2 path being used anywhere. Because no-one knows what that means, except it's patterned after legacy mapping of device drivers to entries in /dev. On the other hand, I'd sympathise with any end user who wouldn't know how to find the productId of their input device. I'd also sympathise with any user who doesn't understand/know that his MoronClone 5000 is supported by the Aiptek driver... Given that we're dealing with hotplug systems, and are now seeing a series of device mappings to pseudo-devices (unlike, say, /dev/tty01, which always refers to a specific serial port), I'm wondering if there should be a different keyword in the Config file to augment Device... This is half-baked, so I'm throwing it out for comment for than anything: 1. Device /path # same behavior as before 2. DeviceDesc Bus USB ID Wacom EndDeviceDesc The notion here is, something that is matched to the operating system will scan the 'pseudo-mapped' devices, knowing that it's looking for a Wacom device on one of the USB ports. It should come back with an array of paths (in case you have more than one tablet), which the device driver loader then uses as it's path for opening the handle. In the current non-hotplug environment, one approach might be to enumerate input devices in a way analogous to what we do with video cards, and bind InputDevice sections to hardware with a similar method to that used for Device sections. This would at least allow you to say in your configuration that you want to use a wacom device, and the driver will bind to the first one. Yes, with one cavaet: you require that the user figures out the BusId for the card. Fortunately, so far, the card doesn't move from slot to slot on its own... I've been doing some things to allow the mouse driver to automatically find a device without having to be told where to find it. But I'm looking at this stuff from the point of view of handling the most common user situations now, while working towards a more general solution rather than holding everything up until the general solution is worked through. So you are looking at a list of likely candidates to see who really has a mouse connected? (E.g., /dev/psaux, /dev/input/mouse0, /dev/mouse) That's fair. If you relied on kudzu or discover, you might know exactly where/what you have. Interestingly, in Linux, /proc/bus/input/devices tells us what we'd like, using key data points the user would know, I: Bus=0011 Vendor=0001 Product=0002 Version=ab02 N: Name=AT Set 2 keyboard P: Phys=isa0060/serio0/input0 H: Handlers=kbd event0 B: EV=120003 B: KEY=4 200 c061f9 fbc9d621 efdfffdf ffef fffe B: LED=7 I: Bus=0011 Vendor=0002 Product=0001 Version=000b N: Name=PS/2 Logitech Mouse P: Phys=isa0060/serio1/input0 H: Handlers=mouse0 event1 B: EV=7 B: KEY=7 0 0 0 0 0 0 0 0 B: REL=3 I: Bus=0003 Vendor=08ca Product=0020 Version=0100 N: Name=Aiptek P: Phys=usb-:00:1f.4-2/input0 H: Handlers=kbd mouse1 event3 B: EV=1f B: KEY=1c5f 0 7 0 0 0 ff f00 ffa0001f f800 3 B: REL=303 B: ABS=d000103 B: MSC=1 Well, it tells you you have a mouse, but doesn't tell you it's mapped at /dev/misc/psaux. It mistakenly tells you it's mapped to /dev/input/mouse0, but truthfully tells you about /dev/input/event1. It all dances around the question, so I'll restate it. You know you have hardware made by vendor 'X', model 'Y'. You may know bus 'Z'. You know through experience that /dev/somepath is something that's changeable, because it doesn't refer to a specific hardware interface (e.g., /dev/tty01, or /dev/usb/2-2:0) but something virtual. Add hotplug to make it more fun. Do you, 1. Rig up the XF86Config file so you
XF86Config-4 parser
David, How is the work on the XF86Config parser coming? I ask because I noticed that the 'Option Device /dev/input/event?' is getting weird, like I thought it would when we were discussing Input System improvements. Specifically, my tablet seems to have chosen for it different /dev/input/event? paths where it is mapped to during boot-up. For several times, it's mapped to /dev/input/event2, then after a subsequent reboot, it moves to /dev/input/event1 for awhile... Given that we're dealing with hotplug systems, and are now seeing a series of device mappings to pseudo-devices (unlike, say, /dev/tty01, which always refers to a specific serial port), I'm wondering if there should be a different keyword in the Config file to augment Device... This is half-baked, so I'm throwing it out for comment for than anything: 1. Device /path # same behavior as before 2. DeviceDesc Bus USB ID Wacom EndDeviceDesc The notion here is, something that is matched to the operating system will scan the 'pseudo-mapped' devices, knowing that it's looking for a Wacom device on one of the USB ports. It should come back with an array of paths (in case you have more than one tablet), which the device driver loader then uses as it's path for opening the handle. Obviously, if you have more than one device with the same description, a) You need something to further differentiate the units. Perhaps something like SerialNum xxx or modelNum yyy , or just FirstOne. b) If there is a lack of differentiating data, then 1-to-many devices are mapped to 1-to-many instances of the same driver. Have to do something at the identifier to uniquely ID them -- appending an incrementing integer works. Thoughts? Flames? Arguments? I like 'em... -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Touchscreen input driver
Bodo Bimboese wrote: Hello All, Please apologize if this request is wrongly placed. I'm not familiar with programming, just a keen user. I'd be thankful, if anybody could point me into the right direction. I'm using X (4.3.0) on Linux, and I'm struggling to get a touchscreen (-input) device to work. It's not one of those popular manufacturers whose driver is included with 4.3.0 Things I've found out yet: manufacturer of the 12 TFT monitor with touchscreen is a no-name Asia-based. The interface is RS-232 with 9-pin serial connector and a PS/2 dongle-style plug (the mouse plugs into the back of this plug). Touchpanel manufacturer is a company called Hantouch Serial driver PCB manufacturer is a company called Sena (both companies offer downloads, but I didn't found any for X) The monitor is marketed under the label Glancetron in Europe (They only offer Win drivers unfortunately) Since I haven't found any *nix drivers on the net, I've tested all input drivers which came with X. None of the touchscreen drivers work, some cause X to abort. The only reaction I get is from the DigitalEdge tablet driver, which causes a 'click' in the bottom right corner of the screen, no matter on which area I touch it. My question is: Would it be an easy task to modify an existing driver to get the touch element to work? I've had a look at the Elotouch driver sources, and it doesn't look huge. I have no idea about programming, but I'm motivated to take the challenge. Sure, but you need to know what the incoming packets look like. Have you dropped a line to Hantouch? If you have, and they're unwilling to help, you probably can track RS-232 communications between the touchscreen and the Windows driver... Good luck! -- .:. 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: 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...
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...
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...
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: New device handling in X
Elliott Mitchell wrote: From: Bryan W. Headley [EMAIL PROTECTED] Egbert Eich wrote: Bryan W. Headley writes: 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... Your model is almost the model of a SpaceMouse and other 6Dof controllers. What about pen pressure? You could treat it as negative Z values, but what if you've got a block of wood on top of the tablet? If the tablet could still read the pen position you could have pressure without Z being zero. More realistic is pens with erasers, if pressure can be read on the eraser then the pen point is going to be well away from the tablet and you need to be returning pressure. Pen pressure is considered to be 'Z'. Which is stupid because it isn't, and further my tablet's able to detect the stylus even when it's held 6 inches away from the surface -- problem is, it doesn't know how far away it is, only that there's marginal pressure. I'd have to know more about the SpaceMouse. Cursory reading tells me it was previously known as Magellan -- does the magellan device driver support the current product? I see that they read 6 axis, but what a, b, and c model is not immediately apparent. Given the trend of current input devices, an argument can be made to instead of having buttons and axes, simply have digital mode and analog mode. Particularly in gamepads they've been moving away from simple switches to buttons that can detect pressure. Though keyboards which can detect pressure on every key are not yet here, such a thing could come in the future. Then there are *lots* of ways you could interpret the axes and buttons. I have to suggest the creation of an Xitk library. Perhaps this is merely me, and my interest in games, but a common library that can take care of cooking the input in a standard way would seem to be a good thing. Could solve the problem of how to get rid of the old merely linear acceleration of the mouse pointer. 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... Might well provide a useful additions to a grand unified model of input devices. -- .:. 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: 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...
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...
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...
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...
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...
[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...
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
Re: Questions about Widgets in X window and XMoveResizeWindow
dd jj wrote: Thank you. But it seems XRunner is not avaliable on Linux. Any other tools I can use? Whether free or not... Huh? Their site says it runs on RedHat... I just found this with Google... http://sourceforge.net/projects/x11guitest -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: pls help a newbie:how XFree86 wrap functions in libc
Rafa? Rzepecki wrote: On Tuesday 12 of August 2003 05:48, Tao, Qian (陶� IES) wrote: I'm sorry,my english is not good I want to add some code to xc/program/Xserver/hw/xfree86/input/mouse/mouse.c I have to call some functions in libc. To my surprise,fprintf wok well,but,gettimeofday doesn't work When I start my server,the server says:This should not happen;An unresolved function was called;Fatal server error I just cannot understand how XFree86 wrap functions in libc. Pls help me, and you can give me some docs What kind of functionality are you exactly trying to add? IMHO you should not call libc functions directly in drivers, especially those manipulating files. It's bad practice, and AFAIK it's security breach, because drivers work as root. I'm working on mouse.c personally, trying to add cordless mouse status reporting and some cordless-specific runtime control, such as RF channel switching. Unfortunately the only way I've found to communicate with userland is using shared memory (vide synaptics driver). But it has a drawback that it cannot be used to communicate with remote display, as it's not using the X protocol. One could try to communicate using LED feedbacks (like in citron driver), but there seem to be no way to manipulate feedbacks of the core pointer, so it's limited to extension devices. Or maybe I am mistaken, and there is a way? Could someone more familiar with input drivers clarify it? I'm not aware of any restriction with the mouse driver. But I think the LED feedback is very limited, both in terms of packet size, and in terms of reply. Possibly, we can activate StringFeedback and at least get larger packets, (it's a one-line patch), but until we do something using Atoms, you will suffer due endianness/sizeof intrinsics/padding issues. Excuse my stupidity, why are you not using GetTimeInMillis? OTOH, we could wait for the message passing in Xext to extend to input drivers, as I have read somewhere there is someone working on it. How's progress with that? -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: pls help a newbie:how XFree86 wrap functions in libc
Rafa? Rzepecki wrote: Another thing you can use is the xf86Misc message extension. The ati/radeon driver shows a stub of it (xf86HandleMessageProc) But isn't it only usable by display drivers? I don't see anything that specifically says deliver this only to display drivers; on the other hand, I don't see where you get to specify WHICH device you are writing to. Every device driver serving Display* x, screen y? -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: pls help a newbie:how XFree86 wrap functions in libc
Rafa³ Rzepecki wrote: On Tuesday 12 of August 2003 16:53, Bryan W. Headley wrote: I'm working on mouse.c personally, trying to add cordless mouse status reporting and some cordless-specific runtime control, such as RF channel switching. Unfortunately the only way I've found to communicate with userland is using shared memory (vide synaptics driver). But it has a drawback that it cannot be used to communicate with remote display, as it's not using the X protocol. One could try to communicate using LED feedbacks (like in citron driver), but there seem to be no way to manipulate feedbacks of the core pointer, so it's limited to extension devices. Or maybe I am mistaken, and there is a way? Could someone more familiar with input drivers clarify it? I'm not aware of any restriction with the mouse driver. From XChangeFeedbackControl (3x11): BadDevice An invalid device was specified. The specified device does not exist or has not been opened by this client via XOpenInputDevice. And you can only XOpenDevice if it is not a core pointer: BadDevice An invalid device was specified. The specified device does not exist, or is the X keyboard or X pointer. [XOpenDevice (3x11)] Or maybe there is another way to manipulate feedbacks that I am not aware of and it helps to get this problem around? But I think the LED feedback is very limited, both in terms of packet size, and in terms of reply. Sure, it is limited, but at least it's a way to setup bidirectional driver-userland communication thru the X protocol, and the packet size problem is just a matter of protocol design. And I really don't need any big packets, as the data I am going to exchange is not very large in size. Another thing you can use is the xf86Misc message extension. The ati/radeon driver shows a stub of it (xf86HandleMessageProc) I believe that's what the message passing extension in Xext is going to do. I hope that's the same extension, and we don't have _three_ messaging APIs. Excuse my stupidity, why are you not using GetTimeInMillis? Aren't you called gettimeofday? -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XInput improvements
Alex Deucher wrote: this should be extended to video drivers as well allowing you to dynamically adjust that. I believe THomas Winischofer has done something simialr with his sisctl utility and the sis driver, although I haven't really looked to closely at how that works yet. He has an easier time, given that he has XvGetPortAttribute and XvSetPortAttribute. Just make XAtoms out of his parameters and pass them up and down. Very quick reading of the man page shows you can pass a single XAtom at a time. Would rather have a one-to-many convention to keep communications overhead down... -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Userland - X driver message passing API
The citron input driver overrides the LedFeedbackClass for it's communication API between a client application and the driver. The Aiptek driver too will use the XInput for userland/driver communications. Although, there are major weaknesses with this API, and I would love to use StringFeedbackClass. It's not presently an available symbol for dynamically loading modules; can I enable it without blowing anyone else up? Also, if someone has seen citron's userland application, I'd love to look at it.. Still, this is all a bandage, and I'd like to see a better API/structures for this. Anyone else working on this that I can share ideas/complaints with? Bryan -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Userland - X driver message passing API
Hey, Is anyone aware of a project to allow a userland tool, such as a front-end GUI, communicate with an X input driver? This is what I want to do, and yeah, there is a bit of overlap Zephaniah Hull's evdev: there are several parameters to my Aiptek tablet driver which should be modifiable once X is running. Among those are active area settings, mouse/stylus button transposal settings and the like. I'd like for it to be bidirectional, insofar as it needs to report it's settings as well as configure itself. To do this properly entails implementing a callback method in the drivers (e.g., it's not for input events but rather for configuration), and something at a higher level that listens to a socket, named pipe, jms, smtp, m-o-u-s-e and can route/dispatch messages to the appropriate driver. Where evdev comes in (I think) is that it establishes a channel of communications to pass along hardware insertion/removal events generated by hotplug. So there's some infrastructure there already: the question is whether leveraging off of that is a good way to go... Any guilty heads out there? -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Aiptek USB tablet driver
Guys, What's the procedure to submit code for approval in next roll of XF86? I saw some code being attached to email, but wasn't sure if that's what you like... Bryan -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Tablet driver for Aiptek HyperPen USB
Thomas Zander wrote: Whoa, funny as hell! I do try.. I have written a driver for the touchscreen of the PaceBlade laptop, and have about the same questions! Plus; - where can I find a list of methods I can call in the driver with API docs? Damn fine question. Like for instance, if I notice relative reports coming in, maybe I should do something to trigger the driver's switching to relative coordinates. Because, I do allow my front-end tool to select relative mode for the tablet. Really, tying in to hotplug, I'd like to know that a tablet's been attached, and if so, to which device entry in /dev/input... I am looking for a way to do timers in the driver... There is an X wrapper around select()... So, one more vote for answers ;) Thanx. I say let's set up a chat channel somewhere, and line up other input device champions, and we can spend 30 minutes or so asking stupid questions until everyone feels comfortable with each other. Do we have a volunteer to ask/answer dumb questions from we newbies? -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: XFree86 Installation Problem
Thomas Zander wrote: On Mon, Feb 10, 2003 at 12:55:13PM -0800, Mete Kural wrote: Hello All, We bought a brand new PC and installed Red Hat 8.0 on it. The video card didn't work because there are no drivers for the on-board Intel 845 video card in the version of XFree86 shipped with Red Hat 8.0. On Intel's website it was recomended to download the latest CVS snapshot of XFree86. So I downloaded all of the binaries for the latest CVS snapshot of XFree86, which is 4.2.99.901. I installed all of the packages in that snapshot and overwrote my old configuration files. Now when I restart the computer, it goes into the X window environment but the message dialog box in the lower right corner keeps on printing console log localhost.localdomain over and over again and doesn't do anything else. The mouse stays as a sandbox and the system doesn't respond to anything. Do you have any suggestions what I may have done wrong? Should I not have overwritten the old configuration files? Why does the message box keep on printing console log localhost.localdomain over and over? I would greatly appreciate any help. First of all, I suggest you talk to RedHat for support on stuff specific to their distro, which is lots in your case. Heh heh heh. And the first thing they'll say is, you overwrote what with what?!? This will teach you, building code with rpm is good; just open the .spec file, change the name of the tarball, figure out which patches still need to be applied, and give it a rip! Or try the version that's with Phoebe... You will probably need to create a correct config file using RedHats config utility (no idea how that works). Used to be Xconfigurator in 7.x. Cursory look at 8.x tells me they're running XFree86 -configure. I recall that a previous version of anaconda allowed X reconfigures after installation. It's been awhile, so I forget how to do it. Unfortunately I understand from your message you are not able to get into a console to type any commands. If RedHat boots with lilo you want to type the kernel name that normally appears and type 'single' behind that line. You should be able to login then, if that was unsuccessful; ask RedHat support on how to get into your machine in single user mode. When logged in; change your /etc/inittab to start in multiuser mode. It is probably 'multiuser mode with xdm' at the moment. This means changing the line to: id:2:initdefault: I don't know if RedHat also uses '2' Level 3, I thought. After rebooting you can login and configure your graphics card as usual. Hope that helps. -- .:. Bryan W. Headley - [EMAIL PROTECTED] ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
