Re: New device handling in X (was: XInput: The device type in XListInputDevicescomes up again...)
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. 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. -- (\___(\___(\__ --=> 8-) EHM <=-- __/)___/)___/) \ (| [EMAIL PROTECTED] PGP 8881EF59 |) / \_ \ | _ -O #include O- _ | / _/ \___\_|_/82 04 A1 3C C7 B1 37 2A*E3 6E 84 DA 97 4C 40 E6\_|_/___/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Help on creating a Window Manager
Hey Peter, I had your same wishes a while ago and the same proble struck me: the lack of of information about it. One good thing is that all window managers are open source, so what I did was to download all the source I could and investigate how they work. I suggest you the same. Look for the small ones, with the few features and try understand how they work. Getting a copy of the X Window API might also help. I'm sorry I can't really help much, but the truth is that I dropped this little project of mine and if I have any more information I will send to you. best rgds, Pedro Teixeira On Sunday 31 August 2003 8:59 pm, Peter Poulsen wrote: > hi > > I'm playing around with xlib, and is trying to make a window manager > (just because I can ;-)). But the problem is that I need a little more > information. Is there some good resources anybody know of? Also, is > there a mailing list that is more suited for questions related to the > use of xlib (as far as I understand this mailing list is conserned with > the development of xfree, rather than the use of xlib)? ___ 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...
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...
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? Date: Thu, 3 Apr 2003 08:16:02 -0800 (PST) From: David Dawes <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] List-Id: CVS commit messages from the XFree86 repository Subject: CVS Update: xc (branch: trunk) CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/04/03 08:16:02 Log message: 34. Add a new request to the XF86Misc extension that allows a client to send an arbitrary message to the DDX, which in turn can send the message to the driver. The driver may also send a string back. An example of this is implemented for the radeon driver (#5518, Joe Moss). Date: Thu, 3 Apr 2003 08:20:24 -0800 (PST) From: David Dawes <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] List-Id: CVS commit messages from the XFree86 repository Subject: CVS Update: xc (branch: trunk) CVSROOT:/home/x-cvs Module name:xc Changes by: [EMAIL PROTECTED] 03/04/03 08:20:24 Log message: 35. Allow an arbitary message to be sent to the DDX by pressing a key which has the appropriate action definition (#5519, Joe Moss). -- Mike A. Harris ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Re: Help on creating a Window Manager
On Sun, Aug 31, 2003 at 08:59:39PM +0200, Peter Poulsen wrote: > > I'm playing around with xlib, and is trying to make a window manager > (just because I can ;-)). But the problem is that I need a little more > information. Is there some good resources anybody know of? Also, is > there a mailing list that is more suited for questions related to the > use of xlib (as far as I understand this mailing list is conserned with > the development of xfree, rather than the use of xlib)? The main resources are the ICCCM, the EWMH, and the source code of other window managers. twm is small and simple to learn from, though doesn't support the newer EWMH spec. Don't try to read the WM chapter in the Nye book, it's mostly wrong. Havoc ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
Help on creating a Window Manager
hi I'm playing around with xlib, and is trying to make a window manager (just because I can ;-)). But the problem is that I need a little more information. Is there some good resources anybody know of? Also, is there a mailing list that is more suited for questions related to the use of xlib (as far as I understand this mailing list is conserned with the development of xfree, rather than the use of xlib)? -- Yours Peter Poulsen ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
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...
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
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: New device handling in X (was: XInput: The device type inXListInputDevices comes up again...)
Claus Matthiesen writes: > This is a summation of the discussion between the est. Bryan W. Headley, > the est. Egbert Eich and myself so far, along with a few new ideas... > > OK. Most people seem to think we need a new way to do device handling of > what is currently called extended devices in X. I, as an applications > programmer, find that it is far too restrictive and very importantly > that the device drivers written for it do not sufficiently conform to > the documentation, and the device programmers find that it cannot > express all the aspects of a modern Human Input Device (or HID). > > There are two choices: Either to fix the old broken API or to make > something new and phase the old API out. > > In favor of fixing the old API is the fact that making a new one would > mean going over every driver to make them conform to the new API. This > is a large task. Besides, people know the old API. > We need to keep compatibility to the old API, which means when a client with an earlier version connects we'd have to deliver the events of the old API. Therefore keeping what is OK about the old API actually makes a lot of sense. I need to think a little bit more about your ideas. 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...
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...
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: "ucs2any" is used twice
On Fri, Aug 29, 2003 at 05:56:34PM +0200, Matthieu Herrb wrote: > > scanning through the log of a XFree86 4.3.0 I found out that "ucs2any" > > is invoked two times for each font at different stages of the build > > process. Is that a known problem? While it isn't a big problem for > > a fast x86 system it is quite painful on slower architectures because > > it increases the build time significantly. > Can you provide some detail (some chunks of your log file for > instance) I can't see that with the few fonts I checked on my logs > from -current builds on OpenBSD. I've checked the logs again and found that I was apparently wrong. While you can find some "ucs2any" command multiple times in the logfile they are executed in different directories. I'm sorry for the false report. Kind regards -- Matthias Scheler http://scheler.de/~matthias/ ___ Devel mailing list [EMAIL PROTECTED] http://XFree86.Org/mailman/listinfo/devel
