PDA

View Full Version : relative mouse coordinates



zen
12-31-2003, 08:35 AM
I'm currently (re-)looking into this matter and I have found out the following:
1)Standard Xlib events. Requires XWarpPointer hack and therefore sucks (both performance-wise and style-wise). Semi-usable though
2)DGA 2.0(1.x is deprecated, right?). Requires fullscreen mode(not that I've been able to set it up even in fullscreen, but thats what I hear) and is therefore quite useless for window/fullscreen apps. So generally not usable.
3)XInput extension. This doesn't seem to work with the X11 corepointer device (XOpenDevice fails) so I suppose that it requires special configuration of the X server or is only intended for non-core devices which also makes it not usable.

Does anyone know anything else about this that might be of interest? Is XWarpPointer the only way to go?

[This message has been edited by zen (edited 12-31-2003).]

azcoder
12-31-2003, 11:27 AM
If you are trying to read the mouse, have you considered using SDL?

It is a cross-platform library for input, sound, and events. They do have realtive mouse reads.

Good Luck!

zen
01-01-2004, 10:48 AM
Well I don't want to use SDL for something as simple as this. In fact I don't want to use SDL in general if I can avoid it. Although I doubt it with this windowing system chaos I have to deal with.

ecote
01-09-2004, 06:13 AM
has anyone solved this problem?.. my current project really needs this to be solved

ZbuffeR
01-09-2004, 08:55 AM
For something like that, GLFW is really good.

zen
01-09-2004, 04:31 PM
Well I'm afraid I don't have any good news. Method 1 seems to work ok although it still remains a hack. For method 2 I'm not sure if it's even usable since it doesn't seem to be meant for opengl. Besides requiring fullscreen mode to initialize DGA, the only way to render to it using the GL seems to be to get a pixmap pointing to the framebuffer and then bind it to a context. Problem is that according to the GLX specs binding a direct rendering context to a pixmap is not guaranteed to succeed so I don't feel good about doing, it even if it would work ok on my system (haven't tried it). As for method 3 , I haven't found out much more about it.
Btw, why are there only all-in-one wonder libraries out there? I mean DGA means Direct Graphics Access (or something like that) doesn't it? What have mouse and keyboard events have to do with graphics? They could be implemented in a seperate extension. Even small libs like GLFW try to do a little of everything (threads, texture loading etc.) There are other libraries (like OpenIL for textures) that do those things much better.
We definately need some nice, small, clean, portable libraries for window management, input etc.

[This message has been edited by zen (edited 01-09-2004).]

l_belev
01-10-2004, 06:44 AM
using XWarpPointer is the only sane way
to go (the only one other way is by using
DGA 1, but it's deprecated). It certaily
looks hackish and ugly, but otherwise it
has no other problems - it's a core X
functionality (and hence it's always
available, in contrast with the various extensions), and it has no
performance/speed issues: don't forget that
whatever amount of work you do to process
an mouse event, it's consumed CPU time
will be nothing when compared to the time
between the mouse events (max 100 such
events per second), so here the performance could be an issue only on, say, 25MHz 386.
The only problem about XWarpPointer is
really aesthetical, but sometimes one has
to compromise his/her goot taste.

zen
01-17-2004, 01:44 PM
For some reason I couldn't post here until today, I got a server error page.



and it has no performance/speed issues


Are you sure about that? I would believe so too (although you do have the extra overhead of two XSelectInput()s one XWarpPointer() and a few integer operations) but I've read various posts etc. where people said that this method is inferior in resolution/smoothnes whatever than XWarpPointer. Actually now that I think of it it must be so. A good mouse will have a much higher resolution than the screen (because this method's resolution is only as good as the screens resolution). The screen has typically say 90dpi resolution and I remeber reading on the boxes of some very old mice that they had a resolution of 600dpi. Current mice should be much better than that. This is certainly unacceptable for some purposes(li
ke fps games for instance).



The only problem about XWarpPointer is really aesthetical, but sometimes one has to compromise his/her goot taste.

Or write his/her own X extension...

Btw are you sure tha thet XInputExtension cannot be used for this purpose?

[This message has been edited by zen (edited 01-17-2004).]

l_belev
01-18-2004, 10:20 AM
The resolution could in theory be an issue but so far I haven't seen any such case (for instance in quake3 i get even better mouse behaviour than under windows). One possible reason for seemingly bad resolution, i can think of, is if someone forget to take the mouse acceleration into consideration (man XGetPointerControl).

>Or write his/her own X extension...

ok, feel free do so, but after that you will have to convince the XFree86 guys to incorporate your extension, which i suspect would prove a bit hard :-)

XInputExtension covers only the extra input devices (like joystices), if any. It does not deal with the core input devices - the mouse and the keyboard (read the beginning of the XInputExtension spec).

l_belev
01-18-2004, 10:44 AM
what XSelectInput do you speak of? You should do it only once - on init (or never, if you select the motion event otherwise). On every received motion event you should only call XWarpPointer. Are you doing something wrong?

zen
01-18-2004, 10:56 AM
If I just call XWarpPointer then the call itself will generate a PointerMotion event wich in turn will call XWarpPointer again etc. and I will soon end up with a flooded event queue. But I suppose you allready knew that and checked wether the pointer is on position width/2,height/2 (or whereever you warp it) in wich case you don't call XWarpPointer. This can be done as well. I call XSelectInput to deselect MotionPointer events before calling XWarpPoitner and restore it afterwards. Seems less hackish this way but I'll change it if I find it to be slower than the alternative.
Regarding XInput, it does have support for mice and keyboards but I can't 'open' the core devices. Maybe there is a way to configure the core devices as extended input devices (in XF86Config). This might be a viable solution, I might look into it.

l_belev
01-18-2004, 12:27 PM
I see. I'm doing it the other way around - ignoring the superfluous events. I think that's the better variant, but you decide for yourself.

Don't believe me about XInputExtension? Then why do you ask at all? Go and read the spec yourself. As I mentioned, there it is written.

l_belev
01-18-2004, 01:25 PM
btw, a little advice about the mouse acceleration. When you want do disable it, it's better not to really disable it (with XChangePointerControl) but instead to nullify it: get the accel values with XGetPointerControl and apply the inversed function on the pointer coordinates you get from the motion events. This way you would achieve the same effect, but with one extra benefit. If you just disable the accel settings, you would have to restore the original settings before your app exit, but if it crashes, or get killed for some reason, it would be impossible to restore, and that could be rather annoying for the user. But if you dont change the setting, your app may freely crash and you won't have to worry about the restoring of the setting.

l_belev
01-18-2004, 02:52 PM
here is why i don't think using XSelectInput isn't a good approach:
1) this does not make the false event to just dissapear - they may go to some other window and get received by some other X client, which will cause that client to get awaked from it's sleep (get CPU time slice) - which is completely undesired side effect.
2) there's a chance a real motion event to occur in the tiny interval when the motion events are deselected, in which case you would miss it (you would also miss to warp the pointer then).
3) if you have grabbed the pointer, you will still receive the event unless you ungrab and then grab it again (which complicates the software. Also if you temporarily ungrab the pointer, someone else may take the chance and grab it before you manage to re-grab it again.

Instead just ignore the false events and you loose all your problems http://www.opengl.org/discussion_boards/ubb/smile.gif

l_belev
01-19-2004, 01:12 PM
correction to my previous post: you can prevent the motion events from reaching other clients by setting your window's do_not_propagate_mask

zen
01-19-2004, 01:29 PM
I see..., you seem to have a point there (with the XSelectInput thingie, three actually). I'll change to your approach. About the XInputExtension. Don't take it personally, it's not that I don't believe you or anything, but I have read a part of the spec and although it does make a distinction between core and extended devices it does support mice. Now I tried opening the core device and it doesn't work but what I said is that if we can configure the mouse as a core device and extended device (two config, entries pointing to the same hw device) then it might be possible to use the extension.
And about the acceleration. I was thinking that it would be worth the while to use it instead of turning it off. Let's assume we have a 640*480 window. Now as it is now with my pointer beeing warped to (320,240) every time it moves I can't get it to move more than 50 pixels away from the center max (10-15 pixels on average). This kills resolution even more. Wouldn't it be better to change the pointer accel. so that it would get close to the window's edge on average? This way we would get much better resolution. Of course the problem is that the accel. settings would difer from mouse to mouse wich would require some sort of calibration but if we want to avoid that maybe some conservative accel. setting can still be used.


damn! I keep getting server errors preventing me from posting. Posting short posts seems to work though, and editing them to longer posts lateron too.


[This message has been edited by zen (edited 01-19-2004).]