Re: Does XOrg not have any proper HID support at all?
The device responds on the axes and the data is provided by X (xinput test returns a 6 dimensional motion vector), the problem is that only two axes can be CONFIGURED (for example button mapped) - at least the manual only mentions X and Y axes, mouse still had a Z-axes for scroll which was one more. I can only attach my XOrg.log in a week or so because the computer where all this setup was done is currently out of order but again, there should be no problem, certainly no errors or warnings, evdev is loaded properly without any complaints. Thanks for your reply! On 07/26/2010 12:59 AM, Peter Hutterer wrote: On Sat, Jul 24, 2010 at 04:23:50PM +0200, Cedric Sodhi wrote: Hello, the device is a SpaceNavigator by 3dconnexion. I think I'll have to revise a big part of what I said: Indeed, the device works with all its axes. That was my mistake. The problem is that the evdev driver does not support any configuration for the addinial axes, nor does it offer as many options as the original mouse driver which doesnt even account for the exinstance of the axes. The evdev driver only supports configuration for an X and a Y axis, which is 2 out of 6 axes. I can't get any of the other axes configured - that's my problem. Please attach your Xorg.log file. evdev does support up to 36 arbitrary axes and the only reason I can explain the lack of the extra axes in your case is if your device mixes relative and absolute axes. Cheers, Peter Again, sorry for the confusion, it have been some weeks since I dropped the issue and only recently I had time to mail to you so I actually forgot part of my own problem. On 07/24/2010 04:00 PM, Greg KH wrote: On Sat, Jul 24, 2010 at 12:24:05PM +0200, Cedric Sodhi wrote: Hello, this is a serious question and a serious issue, as far I can see. For the last month I've been trying all possible workarrounds an tricks I could possibly imagine to get XOrg accept a 6 Degrees Of Freedom HID compliant Input Device Works for me here, have you not used the evdev driver in xorg? The HID driver is in the kernel, not in xorg, and is not a trivial thing to implement (seriously, have you read the HID spec?) What specifically are you having problems with? What are the errors that you get. thanks, greg k-h ___ ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
RE: Glyph rendering
Based on the debug and experiment, geode graphics processor will be used for the middle dword PictOpAdd operation rendering. Because there is no writemask in geode HW, so modulus(%) with 4 must be garanteed using this method at first. With the code improvement, if the destination start point can not be modulus with 4 to zero, we let driver do SW *dest = *dest + *src calculation firstly to the first pixels. Alike, the driver do that SW rendering for the remaining pixels for each line. That is to say, we will make full use of GP of geode to do the rendering. Use a picture to demonstrate: %/4 1 2 3 0 1 2 30 1 2 3 0 1 2 destOffset: x x x x x x xx x x x x x x HW x x x x (x x x x) SW x x xx x x But from my debug, the last dword(content in bracket) is wrongly rendered, so I render the (dest%4 -1) dwords in HW. The next picture is the actually rendered result: %/4 1 2 3 0 1 2 3 0 1 2 3 0 1 2 destOffset: x x x x x x x x x x x x x x HW x x x x SW x x x x x x x x x x That is to say, if the width of glyph is bigger, our rendering performance is better. For my test, x11perf -aa10text: 46400/s x11perf -aa24text: 18300/s They are improved 10 times than before. Thanks, Frank -Original Message- From: Michel Dänzer [mailto:mic...@daenzer.net] Sent: 2010年7月21日 16:24 To: Huang, FrankR Cc: Mart Raudsepp; Torres, Rigo; Writer, Tim; xorg-devel@lists.x.org; xorg-driver-ge...@lists.x.org; Cui, Hunk; Deucher, Alexander Subject: RE: Glyph rendering [ Fixed your quoting, please consider using a better e-mail client ] On Mit, 2010-07-21 at 16:11 +0800, Huang, FrankR wrote: From: Michel Dänzer [mailto:mic...@daenzer.net] On Mit, 2010-07-21 at 15:30 +0800, Huang, FrankR wrote: But as you known, for the PICT_a8r8g8b8 method, the width and height of source sometimes can not be divied by 4(such as 5...), so the remaining pixel PictOpAdd should be done by SW code. The height doesn't matter, and if there's a writemask it should be possible to use that to mask out source/destination pixels that don't align to an ARGB pixel. Yes. My description is not accurate, we only care width for this condition. Do you mean the writemask implemented in HW? From what I found, it is not in geode GP. :( Yes, that's what I meant. For the mixed way(HW+SW as I described above), the speed can be 5/s, unfortunely the result still is not correct(seems correct by debugging, I'm still checking it). Sounds like maybe you're not properly synchronizing between GPU and CPU access. Michael, Ahem. maybe you misunderstand. The SW I mean is that our driver still use a formula to do the + operation in video memory instead of fallback to server handling(may be you means this). We don't fallback anymore. I figured that, which means the driver is responsible for making sure the GPU and CPU properly see each other's rendering results. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Does XOrg not have any proper HID support at all?
On Mon, Jul 26, 2010 at 07:59:56AM +0200, Cedric Sodhi wrote: The device responds on the axes and the data is provided by X (xinput test returns a 6 dimensional motion vector), the problem is that only two axes can be CONFIGURED (for example button mapped) - at least the manual only mentions X and Y axes, mouse still had a Z-axes for scroll which was one more. I can only attach my XOrg.log in a week or so because the computer where all this setup was done is currently out of order but again, there should be no problem, certainly no errors or warnings, evdev is loaded properly without any complaints. Thanks for your reply! So is what you're trying to say that it works fine in terms of passing all the axis events through, but you want to be able to map the other axes to buttons, actions, or? I still don't really understand what your actual problem is. Cheers, Daniel signature.asc Description: Digital signature ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Does XOrg not have any proper HID support at all?
Errata: If you know a GIMP specific or any solution to it, of course I'd like to hear it! I just meant that it could distract the discussion :) On 07/26/2010 03:30 PM, Cedric Sodhi wrote: Ok, in all detail, I would not have neglected to describe the whole situation if I had known that you'd like to hear it - was just trying to keep it short, or, as I usually put it: I was trying to keep it abstract to make it as hard as possible to find a solution. ^^ In my case the application I'm doing this for is The GIMP, but please be reminded that this is just an example and you could take any other application where such problem could occur. So please, even if you know that coming versions of the GIMP solve this or know another, GIMP sepcific solution to this, don't mention it, I'm looking for a generic XOrg specific way which solves this once and for good! Particularily, I want to make a space-navigator device [1] control the view in the GIMP by MAPPING BUTTONS TO AXES, because the GIMP lacks native support to properly map axes to actions. But usually anything interactive such as panning, scrolling, etc requires configuring a specific repeat-rate and of course, the button itsself. EVDev doesn't support proper repeat rates not to mention axes beyond X and Y. I hope this became very clear now. PS: Please rule out other solutions, I've quite checked everything and X is not only the only possible options, it is also the GENERIC and THUS PREFFERED way of managing such a setup. Thanks. [1] http://www.3dconnexion.com/products/spacenavigator.html On 07/26/2010 02:11 PM, Daniel Stone wrote: (Please don't drop the list from CC.) On Mon, Jul 26, 2010 at 01:04:10PM +0200, Cedric Sodhi wrote: Yes. In more detail: Evdev does not appear to have ANY mention of other axes besides X and Y in its config - which renderes it practically a mouse driver rather than anything HID related. What _exactly_ are you trying to do? ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] configure.ac: Include math.h when checking for sqrt/cbrt
On Mon, Jul 26, 2010 at 05:48:10PM +0200, Mark Kettenis wrote:
From: Daniel Stone dan...@fooishbar.org
Date: Mon, 26 Jul 2010 16:31:15 +0100
sqrt and cbrt are only defined in math.h, so we have to include that
when checking for them, lest we miss it, and then some other header
pulling in math.h causes build failures due to multiple definitions.
Eh, why? AC_CHECK_LIB is supposed to check whether these symbols are
available in the given library in a way that doesn't depend on a
prototype for them being in scope. So I don't see what you diff
achieves, other than adding more clutter to the configure scripts.
Well, it does depend on a prototype for them being in scope. It
constructs a basic int main(...) { foo(); } bit of source with
AC_LANG_CALL and then attempts to link it:
AC_DEFUN([AC_CHECK_LIB],
[m4_ifval([$3], , [AH_CHECK_LIB([$1])])dnl
AS_LITERAL_IF([$1],
[AS_VAR_PUSHDEF([ac_Lib], [ac_cv_lib_$1_$2])],
[AS_VAR_PUSHDEF([ac_Lib], [ac_cv_lib_$1''_$2])])dnl
AC_CACHE_CHECK([for $2 in -l$1], [ac_Lib],
[ac_check_lib_save_LIBS=$LIBS
LIBS=-l$1 $5 $LIBS
AC_LINK_IFELSE([AC_LANG_CALL([], [$2])],
[AS_VAR_SET([ac_Lib], [yes])],
[AS_VAR_SET([ac_Lib], [no])])
LIBS=$ac_check_lib_save_LIBS])
AS_VAR_IF([ac_Lib], [yes],
[m4_default([$3], [AC_DEFINE_UNQUOTED(AS_TR_CPP(HAVE_LIB$1))
LIBS=-l$1 $LIBS
])],
[$4])
AS_VAR_POPDEF([ac_Lib])dnl
])# AC_CHECK_LIB
And it also solves the exact problem I described in my error message,
which was that AC_CHECK_LIB on cbrt failed, so we'd build our own
version of cbrt, which would cause the compile to fail because math.h
was dragged in, and you'd thus get a mixed static/non-static
declaration. I didn't just write that for fun ...
Cheers,
Daniel
signature.asc
Description: Digital signature
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] configure.ac: Include math.h when checking for sqrt/cbrt
Date: Mon, 26 Jul 2010 16:55:20 +0100
From: Daniel Stone dan...@fooishbar.org
On Mon, Jul 26, 2010 at 05:48:10PM +0200, Mark Kettenis wrote:
From: Daniel Stone dan...@fooishbar.org
Date: Mon, 26 Jul 2010 16:31:15 +0100
=20
sqrt and cbrt are only defined in math.h, so we have to include that
when checking for them, lest we miss it, and then some other header
pulling in math.h causes build failures due to multiple definitions.
=20
Eh, why? AC_CHECK_LIB is supposed to check whether these symbols are
available in the given library in a way that doesn't depend on a
prototype for them being in scope. So I don't see what you diff
achieves, other than adding more clutter to the configure scripts.
Well, it does depend on a prototype for them being in scope. It
constructs a basic int main(...) { foo(); } bit of source with
AC_LANG_CALL and then attempts to link it:
AC_DEFUN([AC_CHECK_LIB],
[m4_ifval([$3], , [AH_CHECK_LIB([$1])])dnl
AS_LITERAL_IF([$1],
[AS_VAR_PUSHDEF([ac_Lib], [ac_cv_lib_$1_$2])],
[AS_VAR_PUSHDEF([ac_Lib], [ac_cv_lib_$1''_$2])])dnl
AC_CACHE_CHECK([for $2 in -l$1], [ac_Lib],
[ac_check_lib_save_LIBS=3D$LIBS
LIBS=3D-l$1 $5 $LIBS
AC_LINK_IFELSE([AC_LANG_CALL([], [$2])],
[AS_VAR_SET([ac_Lib], [yes])],
[AS_VAR_SET([ac_Lib], [no])])
LIBS=3D$ac_check_lib_save_LIBS])
AS_VAR_IF([ac_Lib], [yes],
[m4_default([$3], [AC_DEFINE_UNQUOTED(AS_TR_CPP(HAVE_LIB$1))
LIBS=3D-l$1 $LIBS
])],
[$4])
AS_VAR_POPDEF([ac_Lib])dnl
])# AC_CHECK_LIB
Well, that fragment is supposed to compile fine even without a
prototype for foo(), so there must be something else going on.
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Does XOrg not have any proper HID support at all?
On Mon, Jul 26, 2010 at 4:30 PM, Cedric Sodhi man...@gmx.net wrote: Ok, in all detail, I would not have neglected to describe the whole situation if I had known that you'd like to hear it - was just trying to keep it short, or, as I usually put it: I was trying to keep it abstract to make it as hard as possible to find a solution. ^^ In my case the application I'm doing this for is The GIMP, but please be reminded that this is just an example and you could take any other application where such problem could occur. So please, even if you know that coming versions of the GIMP solve this or know another, GIMP sepcific solution to this, don't mention it, I'm looking for a generic XOrg specific way which solves this once and for good! Particularily, I want to make a space-navigator device [1] control the view in the GIMP by MAPPING BUTTONS TO AXES, because the GIMP lacks native support to properly map axes to actions. But usually anything interactive such as panning, scrolling, etc requires configuring a specific repeat-rate and of course, the button itsself. EVDev doesn't support proper repeat rates not to mention axes beyond X and Y. I hope this became very clear now. PS: Please rule out other solutions, I've quite checked everything and X is not only the only possible options, it is also the GENERIC and THUS PREFFERED way of managing such a setup. Thanks. [1] http://www.3dconnexion.com/products/spacenavigator.html I don't know about axis but xbinkeys supports mapping mouse buttons to any actions you wish. You can even make it send other input events with xte. http://hanschen.org/2009/10/13/mouse-shortcuts-with-xbindkeys/ On 07/26/2010 02:11 PM, Daniel Stone wrote: (Please don't drop the list from CC.) On Mon, Jul 26, 2010 at 01:04:10PM +0200, Cedric Sodhi wrote: Yes. In more detail: Evdev does not appear to have ANY mention of other axes besides X and Y in its config - which renderes it practically a mouse driver rather than anything HID related. What _exactly_ are you trying to do? ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
X.Org modular build problem with xcb
Hi,
I'm not sure if this is the correct place to post this but I'm trying
to build X.Org from git using the wiki instructions for building the
modular tree found at:
http://xorg.freedesktop.org/wiki/ModularDevelopersGuide
When the util/modular/build.sh script tries to build xcb/libxcb it
fails. The last couple lines of the failure look like this:
Making all in src
make[1]: Entering directory
`/home/trevor/devel/code/xorg.modular/xcb/libxcb/src'
/usr/bin/python ./c_client.py -p
/home/trevor/local/packages/xorg.modular/lib/python2.6/site-packages
/home/trevor/local/packages/xorg.modular/share/xcb/dri2.xml
Traceback (most recent call last):
File ./c_client.py, line 1040, in module
module.resolve()
File /usr/lib/python2.6/site-packages/xcbgen/state.py, line 94, in resolve
item.resolve(self)
File /usr/lib/python2.6/site-packages/xcbgen/xtypes.py, line 405, in resolve
self.reply.resolve(module)
File /usr/lib/python2.6/site-packages/xcbgen/xtypes.py, line 369, in resolve
ComplexType.resolve(self, module)
File /usr/lib/python2.6/site-packages/xcbgen/xtypes.py, line 296, in resolve
type = ListType(child, module.get_type(fkey), self)
File /usr/lib/python2.6/site-packages/xcbgen/xtypes.py, line 163,
in __init__
self.expr = Expression(elts[0] if len(elts) else elt, self)
File /usr/lib/python2.6/site-packages/xcbgen/expr.py, line 70, in __init__
self.lhs = Expression(list(elt)[0], parent)
File /usr/lib/python2.6/site-packages/xcbgen/expr.py, line 71, in __init__
self.rhs = Expression(list(elt)[1], parent)
File /usr/lib/python2.6/site-packages/xcbgen/expr.py, line 84, in __init__
raise Exception('XXX')
Exception: XXX
make[1]: *** [dri2.c] Error 1
make[1]: Leaving directory `/home/trevor/devel/code/xorg.modular/xcb/libxcb/src'
make: *** [all-recursive] Error 1
I've attached the entire build log in case the problem is further up.
This problem is reproducible always, and has been happening to me over
the last couple weeks (in other words it wasn't a quick problem that
appeared in the git repository then was fixed). My base system is the
latest openSUSE 11.3. One person has pointed out to me that this
procedure works if using the latest Ubuntu, so it looks like something
in some openSUSE package appears to be colliding with the build's
expectations. Another person pointed out I could route around the
problem by simply commenting out the xcb build portions, however,
seeing how xcb is a rather important component I was hoping to,
someday, understand it better by being able to tinker with it, which
I can only do if I can build it from source.
Anything obvious I'm doing wrong here?
Best regards,
Trevor
LOG.build.xz
Description: Binary data
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Bug: Deadlock for multi-threaded glx apps inside __glXInitialize()
Hi Kristian Testing with current mesa master, my toolkit deadlocks on the first call to a glX function (glXChooseVisual()). The deadlock was probably introduced by your recent commit: glx: Use _Xglobal_lock for protecting extension display list ab434f6b7641a64d30725a9ac24929240362d466 The problem is that the _Xglobal_lock is locked twice inside the __glXInitialize() function of mesa/src/glx/glxext.c, once inside __glXInitialize(), and then as part of dri2CreateDisplay() - ... - XextFindDisplay. The 2nd locking call on the already held lock deadlocks. Attached a backtrace with the problem and a patch/hack that fixes it for me, but introduces a race-condition itself, so this is obviously not the correct solution. The race condition would trigger if two threads would simultaneously do their first call to a glX function for the same Display* dpy handle, rather unlikely to happen in practice? If so, then the patch might be an acceptable fix until a better solution is found? Other applications (glxgears, games etc.) work correctly. The difference is that my toolkit calls XInitThreads() at startup to use xlib multi-threaded and afaik the locking calls only get enabled if xlib is switched to thread-safe mode, otherwise they are no-ops? thanks, -mario 0001-mesa-glx-Work-around-deadlock-on-_Xglobal_lock-in-__.patch Description: Binary data #0 0x0012d422 in __kernel_vsyscall () #1 0x031ccaf9 in __lll_lock_wait () from /lib/tls/i686/cmov/libpthread.so.0 #2 0x031c813b in _L_lock_748 () from /lib/tls/i686/cmov/libpthread.so.0 #3 0x031c7f61 in pthread_mutex_lock () from /lib/tls/i686/cmov/libpthread.so.0 #4 0x0310fba6 in pthread_mutex_lock () from /lib/tls/i686/cmov/libc.so.6 #5 0x0292f41f in _XLockMutex (lip=0x2a25e34) at ../../src/locking.c:107 #6 0x034729af in XextFindDisplay (extinfo=0x0, dpy=0x84debb0) at ../../src/extutil.c:232 #7 0x0344faff in DRI2FindDisplay (dpy=0x84debf0) at dri2.c:81 #8 0x0344fd6e in DRI2QueryExtension (dpy=0x84debf0, eventBase=0xbfffd9cc, errorBase=0xbfffd9c8) at dri2.c:184 #9 0x0344e653 in dri2CreateDisplay (dpy=0x84debf0) at dri2_glx.c:900 #10 0x0342a6ce in __glXInitialize (dpy=0x84debf0) at glxext.c:848 #11 0x0342764a in GetGLXPrivScreenConfig (dpy=0x84debf0, scrn=0, ppriv=0xbfffdbdc, ppsc=0xbfffdbd8) at glxcmds.c:183 #12 0x03427d46 in glXChooseVisual (dpy=0x84debf0, screen=0, attribList=0xbfffdcd8) at glxcmds.c:1495 #13 0x032dae3f in PsychOSOpenOnscreenWindow (screenSettings=0xbfffe114, windowRecord=0x8501010, numBuffers=2, stereomode=0, conserveVRAM=0) at Linux/Screen/PsychWindowGlue.c:288 #14 0x032ee883 in PsychOpenOnscreenWindow (screenSettings=0xbfffe114, windowRecord=0xbfffe110, numBuffers=2, stereomode=0, rect=0xbfffe1b0, multiSample=0, sharedContextWindow=0x0) at Common/Screen/PsychWindowSupport.c:295 #15 0x0330e57c in SCREENOpenWindow () at Common/Screen/SCREENOpenWindow.c:301 #16 0x0334b79b in mexFunction (nlhs=1, plhs=0xb5ee7018, nrhs=4, prhs=0xb5ee7008) at Common/Base/PsychScriptingGlue.cc:959 #17 0x004e0f25 in call_mex(bool, void*, octave_value_list const, int, octave_mex_function*) () from /usr/lib/octave-3.2.3/liboctinterp.so #18 0x006f8868 in octave_mex_function::do_multi_index_op(int, octave_value_list const) () from /usr/lib/octave-3.2.3/liboctinterp.so * Mario Kleiner Max Planck Institute for Biological Cybernetics Spemannstr. 38 72076 Tuebingen Germany e-mail: mario.klei...@tuebingen.mpg.de office: +49 (0)7071/601-1623 fax:+49 (0)7071/601-616 www:http://www.kyb.tuebingen.mpg.de/~kleinerm * For a successful technology, reality must take precedence over public relations, for Nature cannot be fooled. (Richard Feynman) ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: X.Org modular build problem with xcb
On Mon, 2010-07-26 at 17:38 -0400, Trevor Woerner wrote: File /usr/lib/python2.6/site-packages/xcbgen/state.py, line 94, in resolve item.resolve(self) You need the package xcb-proto-1.2 or later which has an xcbgen sub directory which gets installed in /usr/lib/python2.6/site-packages. I ran into this situation recently, but I don't know anything about xcb. I hope it helps. signature.asc Description: This is a digitally signed message part ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: Does XOrg not have any proper HID support at all?
On Mon, Jul 26, 2010 at 03:30:33PM +0200, Cedric Sodhi wrote: Ok, in all detail, I would not have neglected to describe the whole situation if I had known that you'd like to hear it - was just trying to keep it short, or, as I usually put it: I was trying to keep it abstract to make it as hard as possible to find a solution. next time, please detail your problem as good as you can instead of letting others guess what you're trying to do. making it as hard as possible to find a solution by supplying no details serves no purpose other than to waste everyone's time. In my case the application I'm doing this for is The GIMP, but please be reminded that this is just an example and you could take any other application where such problem could occur. So please, even if you know that coming versions of the GIMP solve this or know another, GIMP sepcific solution to this, don't mention it, I'm looking for a generic XOrg specific way which solves this once and for good! Particularily, I want to make a space-navigator device [1] control the view in the GIMP by MAPPING BUTTONS TO AXES, because the GIMP lacks native support to properly map axes to actions. But usually anything interactive such as panning, scrolling, etc requires configuring a specific repeat-rate and of course, the button itsself. EVDev doesn't support proper repeat rates not to mention axes beyond X and Y. evdev doesn't support mapping buttons to axis. the half-exception here is the wheel code but that maps axes to buttons, not the other way round. It's possible hook this up though as you mention there will be the need to cater for repeat rates, delta handling, handling for multiple axes with different repeat rates and deltas, and the handling of absolute axes vs. relative axes when mapping to button events. even then, you could only map to buttons, not whatever those buttons will eventually do in the client. so support for this would be quite intrusive. Since I think this is a rather narrow use-case, feel free to submit a patch but please make sure it is as clean as as possible. even then, i'm hesitant to apply this. Cheers, Peter I hope this became very clear now. PS: Please rule out other solutions, I've quite checked everything and X is not only the only possible options, it is also the GENERIC and THUS PREFFERED way of managing such a setup. Thanks. [1] http://www.3dconnexion.com/products/spacenavigator.html On 07/26/2010 02:11 PM, Daniel Stone wrote: (Please don't drop the list from CC.) On Mon, Jul 26, 2010 at 01:04:10PM +0200, Cedric Sodhi wrote: Yes. In more detail: Evdev does not appear to have ANY mention of other axes besides X and Y in its config - which renderes it practically a mouse driver rather than anything HID related. What _exactly_ are you trying to do? ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
