Re: after Debianupdate (5-6) XWindows didnt start anymore
On Tuesday 01 March 2011 16:30:06 Norbert Jeßberger wrote: hi after the Debian update the X-Server didnt start anymore. I have a FujiSiemens Laptop (17'' Display) with an ATI mobility radeon X700. At the frist start after the update Ive got the error: 'failed to load /usr/lib/xorg/modules/drivers/fglrx_drv.so' So I searched in the 'non-free'- Packages for fglrx stuff and installed them. After that ive got the error: 'no supported AMD display adapter foundno dvices detected' I didnt found this problem somewhere. Im a rookie so i hope you can help me :) The config files are at the end. Greetings Norbert Hi Norbert, The pre R600 cards (which includes your X700) are no longer supported by the fglrx driver. When updating you probably moved from an older version of fglrx that still supported your card to a more recent version without support. Try removing fglrx altogether, and install the xf86-video-ati driver (and mesa, if you want 3D) instead. With a recent X server, you should also remove your xorg.conf. The X server should detect your card correctly and load the appropriate graphics driver automatically. Your default keyboard layout setting is probably best handled by an appropriate entry in a modular settings file in /usr/share/X11/xorg.conf.d. HTH. Regards, Magnus ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: dynamic Keyboard activation - desactivation
On Thursday 28 October 2010 09:32:29 MONDON Daniel wrote: -Message d'origine- De : xorg-bounces+daniel.mondon=lpgtechnologies@lists.freedesktop.org [mailto:xorg-bounces+daniel.mondon=lpgtechnologies@lists.freedesktop.o rg] De la part de Magnus Kessler Envoyé : mercredi 27 octobre 2010 18:19 À : xorg@lists.freedesktop.org Objet : Re: dynamic Keyboard activation - desactivation On Wednesday 27 October 2010 15:31:36 MONDON Daniel wrote: Hi all ! I'am under ubuntu 10.04 live CD. My application doesn't need any keyboard, and I don't want to have one because users are not allowed to modify anything. I know I can do that with xorg.conf file, but + I don't want to have to restart + I an under live CD (I have to move the xorg.conf location ... and reboot). I think I can do that with udev rules, but I don't find anyone who can help me to do that, or any applicable rule sample. :-( Or a simple X command ? Thanks Daniel. I think Peter Hutterer provided an answer to your question recently on this list: See http://lists.freedesktop.org/archives/xorg/2010-October/051507.html In short, if your version of xinput, the device driver and the xorg server is new enough you should be able to do: xinput set-prop device name Device Enabled 0 HTH, Magnus __ With the xinput --set-prop 10 127 0 command, I succed to deactivate mouse. When using xinput, you might be on the safer side if you use the property names, rather than their numeric equivalents. The same goes for the device IDs. So your example should read (I'm inventing the mouse name here): xinput --set-prop My Mouse Device Enabled 0 But this mouse is plugged and identified. Will it be se same thing with a constructor other mouse? It is the same thing with keyboard. But with the xinput --set-prop 11 127 0 command, I have carriage return key pressed every time. Then, I don't think this solution is ok for me! Because I think I can't know the new device id for plugged keyboards or mouse. With what I know, I think it is better to set an udev rule. Am I right? Thanks, Daniel. Again assuming you have a new enough Xorg server (1.8+) you might want to look into using the configuration snippets in /usr/share/X11/xorg.conf.d. Peter Hutterer gave an example of blacklisting earlier on this list: http://lists.freedesktop.org/archives/xorg/2010-October/051405.html In the example he gave a device is blacklisted by name, but in fact you can blacklist an entire range of devices by functionality also: ### /usr/share/X11/xorg.conf.d/01-blacklist-keyboards.conf ### Section InputClass Identifier blacklist all keyboards MatchIsKeyboard on Option Ignore on EndSection ### For an overview of today's xorg configuration capabilities please have a look at Peter's blog posts: http://who-t.blogspot.com/search/label/xorg.conf, especially http://who-t.blogspot.com/2010/01/new-configuration-world- order.html or the documentation for Fedora at https://fedoraproject.org/wiki/Input_device_configuration. And finally, man xorg.conf has some useful information in the InputClass section as well. Cheers, Magnus ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Which package has Xm/XmAll.h
On Monday 07 Sep 2009 22:08:43 Peng Yu wrote: Hi, I don't have root permission in my system. So I can not update packages automatically. Maybe you could try to run your own installation in a virtual machine, where you would have full root control? Can somebody let me know which package at http://ftp.x.org/pub/individual/ include Xm/XmAll.h? None. Xm is the Motif toolkit. Try either the original Motif or openmotif (http://www.openmotif.org). HTH, Magnus Regards, Peng signature.asc Description: This is a digitally signed message part. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Server frozen
With git HEAD of xserver, xf86-video-intel, mesa, libdrm, and the input drivers the X server does not seem to come back once the screen saver in KDE has kicked in and DPMS has turned off the display. This happens on both a laptop with the G45 and a desktop with the 965G graphic chips. The desktop environment is KDE-4.2.4. Both machines run the 2.6.30 kernel, but I had these errors under 2.6.29.4 as well recently, where the server would suddenly freeze with just the mouse pointer being reactive when using a 3D application (including kwin compositing manager). It is possible to log into the machine via ssh, but the server cannot be killed succesfully. Only a reboot brings the display back. The end of the Xorg log shows this error: [mi] EQ overflowing. The server is probably stuck in an infinite loop. Backtrace: 0: /usr/bin/X(xorg_backtrace+0x28) [0x46e648] 1: /usr/bin/X(mieqEnqueue+0x1e4) [0x45daf4] 2: /usr/bin/X(xf86PostMotionEventP+0xd8) [0x471a58] 3: /usr/bin/X(xf86PostMotionEvent+0xa9) [0x471c19] 4: /usr/lib64/xorg/modules/input/synaptics_drv.so [0x7f5d127bb85e] 5: /usr/lib64/xorg/modules/input/synaptics_drv.so [0x7f5d127bdb58] 6: /usr/bin/X [0x47b587] 7: /usr/bin/X [0x5071ea] 8: /lib/libpthread.so.0 [0x7f5d173e6600] 9: /lib/libc.so.6(ioctl+0x7) [0x7f5d15111607] 10: /usr/lib/libdrm_intel.so.1(drm_intel_gem_bo_start_gtt_access+0x4d) [0x7f5d134c97dd] 11: /usr/lib64/dri/i965_dri.so(intelFinish+0x56) [0x7f5d12dd0226] 12: /usr/lib64/xorg/modules/extensions/libglx.so [0x7f5d141c160d] 13: /usr/lib64/xorg/modules/extensions/libglx.so [0x7f5d141c5aee] 14: /usr/bin/X [0x455bc4] 15: /usr/bin/X [0x425d65] 16: /lib/libc.so.6(__libc_start_main+0xfd) [0x7f5d15069a0d] 17: /usr/bin/X [0x4258f9] The problem first appeared for me after the Xi2 code landed in the server. Has somebody else observed this bug? Which component is most likely to cause this? The intel driver, mesa or the server? Many thanks for any pointers. Magnus signature.asc Description: This is a digitally signed message part. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [Intel-gfx] Screen Corruption On Intel GM45
On Saturday 18 Apr 2009 13:57:27 Mike Lothian wrote:
2009/4/17 Magnus Kessler magnus.kess...@gmx.net:
Even with this patch, any non-trivial OpenGL using application will lead
to a garbled screen within its own output window. The rest of the screen
is unaffected.
If the entire screen is corrupted when KDE starts up, this is most likely
due to kwin compositing effects. Mike, can you try to set [Compositing]
Enabled=false in your kwinrc file and restart KDE? This should give you
a working KDE again with HEAD of xserver, although without the bling. Any
OpenGL application you start within that session (or in a plain startx
session with e.g. twm) will still be corrupted.
For me xserver at commit 808fd2c67f303cb721769375b11ce8b90ffc1909 (just
before the DRI2 fake front buffer patches) with the memory leak fix
7b6400a1b8d2f228fcbedf17c30a7e3924e4dd2a applied on top works quite well
for the time being.
Magnus
Yes switching of the bling allows KDE to be usable - glxgears is also
fine
Mike
I find that with the latest DRI2 related patch to xorg-video-intel (commit
5a07ab502fe1e58e7e37fe554fb42d8d2c8c53ec) most OpenGL applications that failed
with the DRI2 fake front buffer patches alone work again with head of Xorg
server. The exception is kwin. Normally it checks for the availability of
certain OpenGL functions and only enables its compositing if all checks
succeed. With current head of Xorg server, xf86-video-intel and Mesa, kwin
compositing is turned off automatically. Forcing it on through
DisableChecks=true leads to a corrupted screen. Ian Romanick suggested on
IRC to verify that kwin uses glXWait{X,GL} correctly. I'm looking into this.
Magnus
signature.asc
Description: This is a digitally signed message part.
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [Intel-gfx] Screen Corruption On Intel GM45
On Friday 17 April 2009, Jesse Barnes wrote: On Thu, 16 Apr 2009 23:04:36 +0100 Mike Lothian m...@fireburn.co.uk wrote: Hi I've noticed some horrible screen corruption using the lastest git xorg intel stack with in X. I've made the screen usable by booting with i915.modeset=0 with Linus's latest tree (this just gives me a back screen with the intel-next tree) I think the problem surfaced the same time as the tiling patches appeared - is there a way to disable tiling to test this? My 2.6.29 and last weeks git kernels would refuse to startx for very long not allowing kde to start (it was possible to recognise the loading screen) it would just crash X then try and start it again The latest intel-next tree allows KDE to start WITH the corruption now when KMS is enabled. When I VT switch the consoles look fine, it's only X that's corrupted Hope this isn't too random a bug report On GM45 you'll need http://git.kernel.org/?p=linux/kernel/git/anholt/drm-intel.git;a=commit;h =f544847fbaf099278343f875987a983f2b913134 which is currently in Eric's drm-intel-next branch. Otherwise in a KMS config the 2D driver will try to use a tiled buffer but the kernel won't set it up properly and you'll just get corruption. Even with this patch, any non-trivial OpenGL using application will lead to a garbled screen within its own output window. The rest of the screen is unaffected. If the entire screen is corrupted when KDE starts up, this is most likely due to kwin compositing effects. Mike, can you try to set [Compositing] Enabled=false in your kwinrc file and restart KDE? This should give you a working KDE again with HEAD of xserver, although without the bling. Any OpenGL application you start within that session (or in a plain startx session with e.g. twm) will still be corrupted. For me xserver at commit 808fd2c67f303cb721769375b11ce8b90ffc1909 (just before the DRI2 fake front buffer patches) with the memory leak fix 7b6400a1b8d2f228fcbedf17c30a7e3924e4dd2a applied on top works quite well for the time being. Magnus signature.asc Description: This is a digitally signed message part. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Radeon DPMS problems? backlight turns back on after a minute
On Tuesday 07 April 2009, Lowell Alleman wrote: Are there any known issues with DPMS not working properly with the latest radeon driver? I've found some old bugs that sound similar, but don't exactly match and the workarounds I've found seem to make a difference. Here is what I'm experiencing: My laptop (IBM T42, r300) LCD will not going into power saving mode on its own. If I force it go into one of these modes, it only stays in that mode for a short period of time (a few seconds to a couple of minutes) before the screen turns back on again. I'm pretty sure this isn't due to any keyboard/mouse events (since the screen saver doesn't pop up a login dialog) and I don't see any new events /var/log/acpid that correlate to the LCD being re-enabled. However, every time the LCD turns back on, I do see the following message in the Xorg.0 log file: enable LVDS. It appears that the X server still thinks that the DPMS mode is enabled, because xset q says that the monitor is still in Suspend (or whatever mode I forced it to be in) even after the LCD was turned on again. Here are some additional details about my setup, and what I've tried: Relevant output from xset q: DPMS (Energy Star): Standby: 600Suspend: 660Off: 1200 DPMS is Enabled Monitor is On After the display has been disabled using xset force suspend the display shuts down. If you check xset q it now reports Monitor is in Suspend. A minute or so later the LCD is turned back on. Now I can see screensaver (which is DPMS-aware, and therefore has been paused to save CPU cycles). At this point, xset q still shows Monitor is in Suspend. I've tried switching between EXA and XAA acceleration. As of radeon v6.12.0 XAA says it is not supported any more, but EXA doesn't appear to be the default yet. (Not sure what that means; but in both cases this problems still occurs). I've also tried adding the NoPM option, as I found as an old workaround suggested, but that didn't make a difference either. Versions: X.Org X Server 1.5.2 Radeon driver: 6.12.0 (I compiled this locally for improved performance in latest release) Linux 2.6.27-11-generic #1 SMP Thu Jan 29 19:24:39 UTC 2009 i686 GNU/Linux Kubuntu 8.10 KDE 4.1.4 I can provide additional info (xorg.conf and Xorg.0.log) if this is an unknown situation and those would be helpful to have. Thanks, - Lowell Hi Lowell, this was a bug in the KDE 4 screensaver code [0]. It is certainly fixed in the latest version of KDE. Try updating to KDE 4.2.1 or above. HTH, Magnus [0] http://bugs.kde.org/show_bug.cgi?id=165265 signature.asc Description: This is a digitally signed message part. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [RFC] glx: fix DRI2 memory leak
On Monday 30 March 2009, Shuang He wrote:
Jesse Barnes wrote:
On Fri, 27 Mar 2009 13:20:25 -0400
Kristian Høgsberg k...@bitplanet.net wrote:
On Thu, Mar 26, 2009 at 6:33 PM, Jesse Barnes
jbar...@virtuousgeek.org wrote:
Ok, I think this is where the leak was:
__glXUnrefDrawable-DrawableGone-__glXUnrefDrawable. This sequence
meant the glxPriv would stay around (since it was used), but
DrawableGone had generally already disposed of the pDrawable before
the call to Unref, so we never got into DRI2DestroyBuffers, thus
the leak.
The loop seems broken to me. It *looks* like DrawableGone should be
the real free routine, only called when a drawable really is free,
so I've fixed up the code to conform to that. This means removing
the GLX priv frees from DRI and DRI2 routines and putting them here
and using the GLX unref routine everwhere (since it will only free
the resource when the refcount reaches 0).
Any thoughts? I'd appreciate some more testers too... I'm not
quite sure about the generic DoDestroyDrawable change, but if the
refcount is always 1 there anyway it shouldn't make a difference
and seems more correct.
The __GLXdrawable is a reference counted object, and the glx code
references it in a couple of places: when there's an X resource
pointing to it (a GLXWindow, GLXPixmap or GLXPbuffer) and when it's
the current drawable or readable for a context. The __GLXdrawable is
allocated by the backend in use (dri, dri2 or swrast) and must be
freed by the same backend (don't mix alloc and free across abstraction
barriers). We unref the __GLXdrawable when we either set a different
drawable/readable and when the X resource goes away.
The leak is (as you pointed out before) because we NULL the pDraw
pointer before calling the backend destructor, which then can't unref
the DRI2Drawable, which we then leak. You had the right fix in the
originial post, we just need to not touch glxPriv after
__glXUnrefDrawable if it got destroyed. I suggest this change to
DrawableGone in irc:
refcount = glxPriv-refcount;
__glXUnrefDrawable(glxPriv);
if (refcount 1) {
glxPriv-pDraw = NULL;
glxPriv-drawId = 0;
}
Yep, that seems to work too... Magnus or Vasily can you guys confirm?
Thanks,
Memory leak problem seems resolved, but I still see X crash with:
(gdb) bt
#0 0xb7fd5424 in __kernel_vsyscall ()
#1 0x03155660 in raise () from /lib/libc.so.6
#2 0x03157028 in abort () from /lib/libc.so.6
#3 0x031925bd in __libc_message () from /lib/libc.so.6
#4 0x031987e4 in malloc_printerr () from /lib/libc.so.6
#5 0x0319c441 in _int_realloc () from /lib/libc.so.6
#6 0x0319d176 in realloc () from /lib/libc.so.6
#7 0x08131002 in Xrealloc (ptr=0x6, amount=0) at utils.c:1133
#8 0x0806d10b in dixAllocatePrivate (privates=0x91487c8, key=0xb7e90a3c)
at privates.c:129
#9 0x0806d1cc in dixSetPrivate (privates=0x91487c8, key=0xb7e90a3c,
val=0x0) at privates.c:193
#10 0xb7e8eca1 in DRI2DestroyDrawable (pDraw=0x91487b0) at dri2.c:218
#11 0xb7eee668 in __glXDRIdrawableDestroy (drawable=0x9205ff0) at
glxdri2.c:108 #12 0xb7ee49bb in __glXUnrefDrawable (glxPriv=0x9205ff0) at
glxutil.c:58 #13 0xb7ee3183 in DrawableGone (glxPriv=0x9205ff0,
xid=12583326) at glxext.c:131
#14 0x0806efdc in FreeResource (id=12583326, skipDeleteFuncType=0)
at resource.c:561
#15 0xb7edffa6 in DoDestroyDrawable (cl=value optimized out,
glxdrawable=12583326, type=1) at glxcmds.c:1225
#16 0xb7ee340a in __glXDispatch (client=0x8d79db8) at glxext.c:523
#17 0x080874cf in Dispatch () at dispatch.c:437
---Type return to continue, or q return to quit---
#18 0x0806c69d in main (argc=2, argv=0xbf9d2754, envp=Cannot access
memory at address 0xbde
Thanks
--Shuang
) at main.c:397
I have observed this crash once as well, but haven't yet found a way to
reproduce it. Can you post a few steps that make this crash more likely? On
the bug report (http://bugs.freedesktop.org/show_bug.cgi?id=20704) you
mention it has something to do with resizing by small amounts.
Thanks
Magnus
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [RFC] glx: fix DRI2 memory leak
On Saturday 28 Mar 2009 00:42:53 Jesse Barnes wrote: Yep, that seems to work too... Magnus or Vasily can you guys confirm? Seems to work fine for me, although I'm going to have an eye open for bugs that might have previously been hidden in the now exposed code paths. Is there any good documentation about resource handling in the server available? I must admit that I get slightly nervous about the loops of function calls that occur when resources are freed. Magnus ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [RFC] glx: fix DRI2 memory leak
On Wednesday 25 March 2009, Jesse Barnes wrote: In trying to track down the memory leak in 20704, I found that the DRI2 drawable destroy routine doesn't seem to get called when new drawables are created and old ones destroyed (as in the glViewport case in the bug). The GLX core code takes care of destroying drawables correctly though, and even calls DestroyPixmap at the right time. However, DRI2 drawables have more state associated with them than just a single pixmap, so we have a __glXDRIdrawableDestroy function that takes care of that. However, by the time we get there, the GLX drawable is gone, so I never saw the if (drawable-pDraw != NULL) DRI2DestroyDrawable(drawable-pDraw); case get triggered... The simple patch below fixed that, but apparently isn't correct (see the bug report) since it causes crashes after a time. My patch was missing another change to set the private-count correctly in dri2GetBuffers though, which may be part of the fix as well. Has anyone else seen this leak? Anyone care to educate me a bit more about GLX drawable lifetime rules? Thanks, Jesse Hi Jesse, This memory leak has troubled me for some time, as it forces me to log out of my X sessions on a regular basis. I have tested your patch and it seems to help tremendously. However, digging through the git commits for glxext.c it appears that the line setting glxPriv-pDraw to NULL was added as part of commit http://cgit.freedesktop.org/xorg/xserver/commit/?id=30bcaa966d6b00f1630609a78db18dee683cc43d which aims to Make glx destroy path handle cases where the X window goes away first. So it might be that the commenter on bug 20704 who observes a crash hits this condition. Maybe Kristian Høgsberg can comment some more. Thanks, Magnus diff --git a/glx/glxext.c b/glx/glxext.c index c882372..73e5a9b 100644 --- a/glx/glxext.c +++ b/glx/glxext.c @@ -127,9 +127,9 @@ static Bool DrawableGone(__GLXdrawable *glxPriv, XID xid) break; } -glxPriv-pDraw = NULL; glxPriv-drawId = 0; __glXUnrefDrawable(glxPriv); +glxPriv-pDraw = NULL; return True; } ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg signature.asc Description: This is a digitally signed message part. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: How To Disable input driver
On Wednesday 11 February 2009, Peter Hutterer wrote: On Wed, Feb 11, 2009 at 08:37:44PM +, Magnus Kessler wrote: On Wednesday 11 February 2009, linux multitouch wrote: Hi I am using Xorg version - 1.5.2 I am developing kernel driver which create /dev/eventX - file. when i insert the kernel driver X11 thinks it's a mouse. how can i configure the X11 to ignore the driver (/dev/eventX) thanks Assuming your Xorg server is configured via hal, you can place a file in /etc/hal/fdi/policy/ that removes the driver key. I use the following file to suppress a joystick from being recognized as an X11 input device: ?xml version=1.0 encoding=ISO-8859-1? deviceinfo version=0.2 device match key=info.capabilities contains=input !-- Match on anything you like from lshal -- match key=input.product contains=SomeProduct Identifier remove key=info.capabilities/ remove key=input.x11_driver/ /match /match /device /deviceinfo Similarly you could use an fdi file to instruct Xorg to use your own input driver. Have a look at the fdi files provided for e.g. synaptics touchpads. Actually, just removing input.x11_driver alone is enough, it's the only thing we really care about in the server. Cheers, Peter Indeed, just removing the input driver key is enough. The line about the capabilities was a left-over from trying to have the joystick NOT recognized as a mouse in the first place. A previous version read something like: remove key=info.capabilities/ merge key=info.capabilities type=strlistinput.joystick/merge merge key=input.x11_driver type=stringjoystick/merge If memory serves correctly without the capabilities lines the joystick driver would not work correctly, as it was getting confused by the buttons. But this was some time ago and I haven't played with the settings recently. Cheeers, Magnus ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: How To Disable input driver
On Wednesday 11 February 2009, linux multitouch wrote: Hi I am using Xorg version - 1.5.2 I am developing kernel driver which create /dev/eventX - file. when i insert the kernel driver X11 thinks it's a mouse. how can i configure the X11 to ignore the driver (/dev/eventX) thanks Assuming your Xorg server is configured via hal, you can place a file in /etc/hal/fdi/policy/ that removes the driver key. I use the following file to suppress a joystick from being recognized as an X11 input device: ?xml version=1.0 encoding=ISO-8859-1? deviceinfo version=0.2 device match key=info.capabilities contains=input !-- Match on anything you like from lshal -- match key=input.product contains=SomeProduct Identifier remove key=info.capabilities/ remove key=input.x11_driver/ /match /match /device /deviceinfo Similarly you could use an fdi file to instruct Xorg to use your own input driver. Have a look at the fdi files provided for e.g. synaptics touchpads. HTH Magnus Kessler ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH 8/9] fb: move some code to mi
On Wednesday 11 February 2009, Maarten Maathuis wrote: commit 734b23e5982e171031077a2d5d6b5dc2a12e1a70 should fix the problem. Thanks, Maarten. In the meantime Eric Anholt committed 5009127de7d9527ae329d1c2fbc7283648bde2e6 (http://cgit.freedesktop.org/xorg/driver/xf86-video- intel/commit/?id=5009127de7d9527ae329d1c2fbc7283648bde2e6) that fixes the issue on the intel driver side. Magnus ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH 8/9] fb: move some code to mi
On Thursday 05 February 2009, Maarten Maathuis wrote: --- exa/exa_accel.c |4 +- fb/fb.h | 37 -- fb/fbcopy.c | 331 +-- fb/fboverlay.c | 2 +- fb/fboverlay.h |2 +- fb/fbwindow.c |2 +- mi/Makefile.am |1 + mi/mi.h | 42 +++ mi/micopy.c | 354 +++ 9 files changed, 406 insertions(+), 369 deletions(-) create mode 100644 mi/micopy.c Removing fbDoCopy and fbCopyRegion from xserver (git commit 2e76958d304a3c4080d62f32449724eeb9b95d93) breaks uxa acceleration in the intel driver. The server crashes as soon as uxa_copy_area or uxa_copy_window are called. At least the equivalent of the exa_accel patch needs to be applied to the intel driver to restore working uxa acceleration with git HEAD of xserver. However, since the intel driver presumably is supposed to work with older versions, too, some version checking might be required as well. A simplistic patch just calling the new mi copy functions is attached. diff --git a/uxa/uxa-accel.c b/uxa/uxa-accel.c index f42e0e2..7053067 100644 --- a/uxa/uxa-accel.c +++ b/uxa/uxa-accel.c @@ -492,7 +492,7 @@ uxa_copy_area(DrawablePtr pSrcDrawable, DrawablePtr pDstDrawable, GCPtr pGC, srcx, srcy, width, height, dstx, dsty); } -return fbDoCopy (pSrcDrawable, pDstDrawable, pGC, +return miDoCopy (pSrcDrawable, pDstDrawable, pGC, srcx, srcy, width, height, dstx, dsty, uxa_copy_n_to_n, 0, NULL); } @@ -840,7 +840,7 @@ uxa_copy_window(WindowPtr pWin, DDXPointRec ptOldOrg, RegionPtr prgnSrc) -pPixmap-screen_x, -pPixmap-screen_y); #endif -fbCopyRegion (pPixmap-drawable, pPixmap-drawable, +miCopyRegion (pPixmap-drawable, pPixmap-drawable, NULL, rgnDst, dx, dy, uxa_copy_n_to_n, 0, NULL); Regards, Magnus Kessler ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] Xvfb: Remove unused function GetLK201Mappings in InitInput.c
Silence a gcc warning. After commit 08363c5830bdea34012dcd954b45ccfdc79a3a7e
GetLK201Mappings is no longer needed.
Signed-off-by: Magnus Kessler magnus.kess...@gmx.net
diff --git a/hw/vfb/InitInput.c b/hw/vfb/InitInput.c
index e53ac4b..578cc49 100644
--- a/hw/vfb/InitInput.c
+++ b/hw/vfb/InitInput.c
@@ -61,201 +61,6 @@ void DDXRingBell(int volume, int pitch, int duration)
#define VFB_MAX_KEY 255
KeySym map[MAP_LENGTH * LK201_GLYPHS_PER_KEY];
-/* The only reason for using the LK201 mappings here was that they were
- * easy to lift.
- */
-static Bool
-GetLK201Mappings(KeySymsPtr pKeySyms, CARD8 *pModMap)
-{
-#define INDEX(in) ((in - VFB_MIN_KEY) * LK201_GLYPHS_PER_KEY)
-int i;
-
-for (i = 0; i MAP_LENGTH; i++)
- pModMap[i] = NoSymbol; /* make sure it is restored */
-pModMap[ KEY_LOCK ] = LockMask;
-pModMap[ KEY_SHIFT ] = ShiftMask;
-pModMap[ KEY_CTRL ] = ControlMask;
-pModMap[ KEY_COMPOSE ] = Mod1Mask;
-
-pKeySyms-minKeyCode = VFB_MIN_KEY;
-pKeySyms-maxKeyCode = VFB_MAX_KEY;
-pKeySyms-mapWidth = LK201_GLYPHS_PER_KEY;
-pKeySyms-map = map;
-
-for (i = 0; i (MAP_LENGTH * LK201_GLYPHS_PER_KEY); i++)
- map[i] = NoSymbol; /* make sure it is restored */
-
-map[INDEX(KEY_F1)] = XK_F1;
-map[INDEX(KEY_F2)] = XK_F2;
-map[INDEX(KEY_F3)] = XK_F3;
-map[INDEX(KEY_F4)] = XK_F4;
-map[INDEX(KEY_F5)] = XK_F5;
-map[INDEX(KEY_F6)] = XK_F6;
-map[INDEX(KEY_F7)] = XK_F7;
-map[INDEX(KEY_F8)] = XK_F8;
-map[INDEX(KEY_F9)] = XK_F9;
-map[INDEX(KEY_F10)] = XK_F10;
-map[INDEX(KEY_F11)] = XK_F11;
-map[INDEX(KEY_F12)] = XK_F12;
-map[INDEX(KEY_F13)] = XK_F13;
-map[INDEX(KEY_F14)] = XK_F14;
-
-map[INDEX(KEY_HELP)] = XK_Help;
-map[INDEX(KEY_MENU)] = XK_Menu;
-
-map[INDEX(KEY_F17)] = XK_F17;
-map[INDEX(KEY_F18)] = XK_F18;
-map[INDEX(KEY_F19)] = XK_F19;
-map[INDEX(KEY_F20)] = XK_F20;
-
-map[INDEX(KEY_FIND)] = XK_Find;
-map[INDEX(KEY_INSERT_HERE)] = XK_Insert;
-map[INDEX(KEY_REMOVE)] = XK_Delete;
-map[INDEX(KEY_SELECT)] = XK_Select;
-map[INDEX(KEY_PREV_SCREEN)] = XK_Prior;
-map[INDEX(KEY_NEXT_SCREEN)] = XK_Next;
-
-map[INDEX(KEY_KP_0)] = XK_KP_0;
-map[INDEX(KEY_KP_PERIOD)] = XK_KP_Decimal;
-map[INDEX(KEY_KP_ENTER)] = XK_KP_Enter;
-map[INDEX(KEY_KP_1)] = XK_KP_1;
-map[INDEX(KEY_KP_2)] = XK_KP_2;
-map[INDEX(KEY_KP_3)] = XK_KP_3;
-map[INDEX(KEY_KP_4)] = XK_KP_4;
-map[INDEX(KEY_KP_5)] = XK_KP_5;
-map[INDEX(KEY_KP_6)] = XK_KP_6;
-map[INDEX(KEY_KP_COMMA)] = XK_KP_Separator;
-map[INDEX(KEY_KP_7)] = XK_KP_7;
-map[INDEX(KEY_KP_8)] = XK_KP_8;
-map[INDEX(KEY_KP_9)] = XK_KP_9;
-map[INDEX(KEY_KP_HYPHEN)] = XK_KP_Subtract;
-map[INDEX(KEY_KP_PF1)] = XK_KP_F1;
-map[INDEX(KEY_KP_PF2)] = XK_KP_F2;
-map[INDEX(KEY_KP_PF3)] = XK_KP_F3;
-map[INDEX(KEY_KP_PF4)] = XK_KP_F4;
-
-map[INDEX(KEY_LEFT)] = XK_Left;
-map[INDEX(KEY_RIGHT)] = XK_Right;
-map[INDEX(KEY_DOWN)] = XK_Down;
-map[INDEX(KEY_UP)] = XK_Up;
-
-map[INDEX(KEY_SHIFT)] = XK_Shift_L;
-map[INDEX(KEY_CTRL)] = XK_Control_L;
-map[INDEX(KEY_LOCK)] = XK_Caps_Lock;
-map[INDEX(KEY_COMPOSE)] = XK_Multi_key;
-map[INDEX(KEY_COMPOSE)+1] = XK_Meta_L;
-map[INDEX(KEY_DELETE)] = XK_Delete;
-map[INDEX(KEY_RETURN)] = XK_Return;
-map[INDEX(KEY_TAB)] = XK_Tab;
-
-map[INDEX(KEY_TILDE)] = XK_quoteleft;
-map[INDEX(KEY_TILDE)+1] = XK_asciitilde;
-
-map[INDEX(KEY_TR_1)] = XK_1;
-map[INDEX(KEY_TR_1)+1] = XK_exclam;
-map[INDEX(KEY_Q)] = XK_Q;
-map[INDEX(KEY_A)] = XK_A;
-map[INDEX(KEY_Z)] = XK_Z;
-
-map[INDEX(KEY_TR_2)] = XK_2;
-map[INDEX(KEY_TR_2)+1] = XK_at;
-
-map[INDEX(KEY_W)] = XK_W;
-map[INDEX(KEY_S)] = XK_S;
-map[INDEX(KEY_X)] = XK_X;
-
-map[INDEX(KEY_LANGLE_RANGLE)] = XK_less;
-map[INDEX(KEY_LANGLE_RANGLE)+1] = XK_greater;
-
-map[INDEX(KEY_TR_3)] = XK_3;
-map[INDEX(KEY_TR_3)+1] = XK_numbersign;
-
-map[INDEX(KEY_E)] = XK_E;
-map[INDEX(KEY_D)] = XK_D;
-map[INDEX(KEY_C)] = XK_C;
-
-map[INDEX(KEY_TR_4)] = XK_4;
-map[INDEX(KEY_TR_4)+1] = XK_dollar;
-
-map[INDEX(KEY_R)] = XK_R;
-map[INDEX(KEY_F)] = XK_F;
-map[INDEX(KEY_V)] = XK_V;
-map[INDEX(KEY_SPACE)] = XK_space;
-
-map[INDEX(KEY_TR_5)] = XK_5;
-map[INDEX(KEY_TR_5)+1] = XK_percent;
-
-map[INDEX(KEY_T)] = XK_T;
-map[INDEX(KEY_G)] = XK_G;
-map[INDEX(KEY_B)] = XK_B;
-
-map[INDEX(KEY_TR_6)] = XK_6;
-map[INDEX(KEY_TR_6)+1] = XK_asciicircum;
-
-map[INDEX(KEY_Y)] = XK_Y;
-map[INDEX(KEY_H)] = XK_H;
-map[INDEX(KEY_N)] = XK_N;
-
-map[INDEX(KEY_TR_7)] = XK_7;
-map[INDEX(KEY_TR_7)+1] = XK_ampersand;
-
-map[INDEX(KEY_U)] = XK_U;
-map[INDEX(KEY_J)] = XK_J;
-map[INDEX(KEY_M)] = XK_M;
-
-map[INDEX(KEY_TR_8)] = XK_8;
-map[INDEX(KEY_TR_8)+1] = XK_asterisk;
-
-map[INDEX(KEY_I)] = XK_I;
-map[INDEX(KEY_K)] = XK_K;
-
-map
[PATCH] Xvfb: add missing include for new xkbsrv.h
Commit 08363c5830bdea34012dcd954b45ccfdc79a3a7e added call to XkbGetRulesDflts defined in xkbsrv.h Signed-off-by: Magnus Kessler magnus.kess...@gmx.net --- hw/vfb/InitInput.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/hw/vfb/InitInput.c b/hw/vfb/InitInput.c index 578cc49..aa90252 100644 --- a/hw/vfb/InitInput.c +++ b/hw/vfb/InitInput.c @@ -39,6 +39,7 @@ from The Open Group. #include mibstore.h #include mipointer.h #include lk201kbd.h +#include xkbsrv.h #include X11/keysym.h Bool -- 1.6.1 signature.asc Description: This is a digitally signed message part. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] .gitignore: ignore sdksyms.dep
Signed-off-by: Magnus Kessler magnus.kess...@gmx.net diff --git a/.gitignore b/.gitignore index bd38ddb..4d277d9 100644 --- a/.gitignore +++ b/.gitignore @@ -150,3 +150,4 @@ include/xkb-config.h include/xorg-config.h include/xorg-server.h include/xwin-config.h +sdksyms.dep -- 1.6.1 signature.asc Description: This is a digitally signed message part. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Random xrandr behaviour
With uptodate git versions of xrandr, xserver, mesa and the intel driver I observe a random behaviour of xrandr. In the same session the output of xrandr randomly switches between $ xrandr Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 4096 x 4096 VGA connected 1280x1024+0+0 (normal left inverted right x axis y axis) 338mm x 270mm 1280x1024 60.0*+ 75.0 60.0* 1152x864 75.0 1024x768 75.0 70.1 60.0 832x62474.6 800x60072.2 75.0 60.3 56.2 640x48075.0 72.8 66.7 59.9 720x40070.1 and $ xrandr Screen 0: minimum 320 x 200, current 1280 x 1024, maximum 4096 x 4096 VGA disconnected 1280x1024+0+0 (normal left inverted right x axis y axis) 338mm x 270mm 1280x1024 (0x3c) 108.0MHz h: width 1280 start 1328 end 1440 total 1688 skew0 clock 64.0KHz v: height 1024 start 1025 end 1028 total 1066 clock 60.0Hz I also observe a more or less pronounced flickering of the screen when xrandr is run. I wonder if the observed behaviour may have the same root cause as the crashes observed with SDL applications when they try to obtain mode lines [0] [1]. Can someone please advise how I could track down this issue further? Regards, Magnus Kessler [0] http://bugs.freedesktop.org/show_bug.cgi?id=17431 [1] http://bugs.freedesktop.org/show_bug.cgi?id=13952 signature.asc Description: This is a digitally signed message part. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: input settings get ignored?
On Sunday 28 December 2008, Bernd Steinhauser wrote: Hi, I was upgrading to xorg-server 1.6 Beta3 (1.5.99.3) and I have one nasty problem, which I'm not sure if it is me doing something wrong or if there is a bug. [snip] In addition to that, some keys don't work or are working wrong, for example, when using the standard layout, the ↑ key acts as a print key. I guess that has something to do with the model or the rules. The up-arrow behaving like the print key is usually caused by using a pc10x keyboard model with the evdev driver. Try using merge key=input.x11_options.XkbModel type=stringevdev/merge in your 10-x11-input-keyboard.fdi file. [snip] Regards, Bernd Regards, Magnus signature.asc Description: This is a digitally signed message part. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: intel X.org crashes on current branches and GM965
On Sunday 21 December 2008, Tobias Hain wrote: Hello, Yesterday I upgraded to 2.6.28-rc9, cleaned all build files, ran autoconfig again and built the binaries: [snip] running KDE 4.1.2. I do see the 2D Desktop just fine, but during loading it crashes at some point (I suspect the compositing manager loading since libglx.so is included in stacktrace). Still the exact same crash (see below). Any ideas? Did I miss anything the last month that my autogen.sh invocations are wrong? Regards, 7oby [snip] Hi Tobias, you might have some better luck with KDE-4.1.3 and above. I believe the underlying problem is in GLX, but some code changes in kwin work around it in recent versions of KDE[1]. HTH, Magnus [1] http://lists.freedesktop.org/archives/xorg/2008-November/040168.html signature.asc Description: This is a digitally signed message part. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Ansification of X.Org code: A question how to proceed
On Tuesday 02 December 2008, Peter Breitenlohner wrote: On Mon, 20 Oct 2008, Alan Coopersmith wrote: In general, I think everyone agrees conversion of the remaining bits of code that use KR/pre-ANSI-C89 style function prototypes declarations to C89 is a good thing (provided it's done correctly [1]), [1] http://invisible-island.net/ansification/index.html Hi Alan, Adam, Julien, Paulo, now with xorg-macros-1.2 available, I have prepared patches to convert libICE and libSM to strict ANSI C as follows: (1) use xorg-macros-1.2 Use XORG_CHANGELOG for rule to generate ChangeLog from git log Use XORG_CWARNFLAGS for compiler warning flags, leave CFLAGS to user (2) Activate CWARNFLAGS with lots of gcc warnings (3) towards ANSI C make default error handlers and some others static (4) ANSI C convert all old style function declarations Hi Peter, can you please check if there is some duplication of effort with the patch to ansify libICE I sent to the list some time ago? http://lists.freedesktop.org/archives/xorg/2008-October/039799.html Cheeers, Magnus signature.asc Description: This is a digitally signed message part. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: No Cursor Movement in X: Slackware-12.1
On Tuesday 02 December 2008, Rich Shepard wrote: If this is not the appropriate list to ask for help, please point me to the proper place. I may not have e-mail access during my business trip this week unless a text browser will allow me to connect to the hotel's server. I just upgraded my Sony Vaio PCG-V505BC from Slackware-12.0 to -12.1 and now the cursor won't move when I start X. Neither the touchpad nor an external USB mouse will move it. However, both the touchpad and an external mouse work on the console with gpm running. The required driver is psmouse, but xorg.conf must have something incorrect (or missing) since it no longer works. Here is the file: # Copyright (C) 1999-2003 Lincoln D. Durey www.EmperorLinux.com GNU-GPL # BlackPerl V505BC XGA XF86Config ATI Radeon M6 X-4.3.0 1024x768x24bpp LCD # USB mouse enabled in the kernel, won't fail if USB support is not present. [snip] Section InputDevice Identifier keyboard0 Driver kbd Option AutoRepeat 250 30 Option XkbOptions ctrl:swapcaps EndSection Section InputDevice Identifier Mouse0 Driver mouse Option Protocol PS/2 Option Device /dev/psaux Option Emulate3Buttons Option Emulate3Timeout 50 Option AlwaysCore Option ZAxisMapping 4 5 EndSection Section InputDevice Identifier USBMouse0 Driver mouse Option Protocol IMPS/2 Option Device /dev/input/mice Option AlwaysCore Option ZAxisMapping 4 5 Option Emulate3Buttons Option Emulate3Timeout 50 EndSection [snip] I've been trying to get this to work for two days now and would greatly appreciate any and all help. I need the notebook for a business trip this week and not being able to run X applications will be a major hinderance. TIA, Rich Hi Rich, I'm not quite sure which version of xorg is shipped with slackware 12.1. Assuming it's a recent one, can you try if you get better success with no xorg.conf file at all or with an xorg.conf file that doesn't contain any InputDevice sections? Make sure that you have the xf86-input-evdev driver installed. If you want full touchpad support (evdev gives basic support) please install xf86-input-synaptics as well. You might want to install and activate hal/dbus (assuming that support for this is built into the slackware packages). Your distro should provide you with some .fdi files that take care of setting up the correct drivers and defaults through hal. HTH, Magnus ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] synaptics: export synapticsModuleData
Mark synapticsModuleData as exported so that it can be used with xorg-server
compiled with visibility flags.
Signed-off-by: Magnus Kessler [EMAIL PROTECTED]
--- src/synaptics.c.orig2008-12-02 21:12:09.0 +
+++ src/synaptics.c 2008-12-02 21:13:23.0 +
@@ -160,7 +160,11 @@
return module;
}
-XF86ModuleData synapticsModuleData = {VersionRec, SetupProc, NULL };
+_X_EXPORT XF86ModuleData synapticsModuleData = {
+VersionRec,
+SetupProc,
+NULL
+};
/*
signature.asc
Description: This is a digitally signed message part.
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xinput test crashes server when touchpad clicked
On Thursday 27 November 2008, Peter Hutterer wrote: On Thu, Nov 27, 2008 at 11:49:58AM +, Magnus Kessler wrote: Tested-by: Magnus Kessler [EMAIL PROTECTED] That patch works fine for me. Thanks for fixing this. However, I see that the same unchecked access to p-key-xkbInfo exists in other functions in xkbEvents.c as well, notably XkbSendStateNotify and XkbSendControlsNotify (where it might be guarded by the xkb_interest field?), XkbSendMapNotify, XkbHandleBell and XkbSendActionMessage. It seems clear from the naming (kbd) of the DeviceIntPtr parameter in those cases that above functions are intended to be called only for regular keyboard devices? Is this guaranteed? IIRC, these functions were always called with the VCK so that wouldn't cause any problems. We can't easily do that anymore, so the bail out if it's not a keyboard is the best approach. I'll amend the patch to fix the other occurances, but it'll take me a few days. If you get to it on the weekend, I'll be happy to review. Cheers, Peter Looks like you beat me to it with with the patch in your latest patch-set for 1.6. Please apply to main as well. Cheers, Magnus ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xinput test crashes server when touchpad clicked
On Wednesday 26 November 2008, Peter Hutterer wrote:
On Wed, Nov 19, 2008 at 10:07:59PM +, Magnus Kessler wrote:
With the latest server and synaptics driver from git I can reliably
crash the server by starting
xinput test SynPS2/2 Synaptics Touchpad
and then clicking the any of the physical buttons or tapping the pad to
simulate a click.
How about this one?
From 87f5aa009d65e44f516bfc0168249ea29433b2b4 Mon Sep 17 00:00:00 2001
From: Peter Hutterer [EMAIL PROTECTED]
Date: Wed, 26 Nov 2008 12:20:00 +1000
Subject: [PATCH] xkb: don't attempt to filter events for devices without
key classes.
Reported by Magnus Kessler.
Signed-off-by: Peter Hutterer [EMAIL PROTECTED]
---
xkb/xkbEvents.c | 10 +-
1 files changed, 9 insertions(+), 1 deletions(-)
diff --git a/xkb/xkbEvents.c b/xkb/xkbEvents.c
index 151849c..02565a4 100644
--- a/xkb/xkbEvents.c
+++ b/xkb/xkbEvents.c
@@ -819,7 +819,8 @@ XkbSrvInfoPtr xkbi;
pXDev = inputInfo.keyboard;
}
-xkbi= pXDev-key-xkbInfo;
+xkbi= (pXDev-key) ? pXDev-key-xkbInfo : NULL;
+
if ( pClient-xkbClientFlags _XkbClientInitialized ) {
if ((xkbDebugFlags0x10)
((xE[0].u.u.type==KeyPress)||(xE[0].u.u.type==KeyRelease)||
@@ -841,6 +842,10 @@ XkbSrvInfoPtrxkbi;
(_XkbIsReleaseEvent(xE[0].u.u.type)) ) {
return False;
}
+
+if (!xkbi)
+return True;
+
if ((pXDev-deviceGrab.grab != NullGrab)
pXDev-deviceGrab.fromPassiveGrab
((xE[0].u.u.type==KeyPress)||(xE[0].u.u.type==KeyRelease)||
@@ -884,6 +889,9 @@ XkbSrvInfoPtr xkbi;
else {
register CARD8 type;
+if (!xkbi)
+return True;
+
for (i=0;inEvents;i++) {
type= xE[i].u.u.type;
if ((xkbDebugFlags0x4)
Tested-by: Magnus Kessler [EMAIL PROTECTED]
That patch works fine for me. Thanks for fixing this.
However, I see that the same unchecked access to p-key-xkbInfo exists in
other functions in xkbEvents.c as well, notably XkbSendStateNotify and
XkbSendControlsNotify (where it might be guarded by the xkb_interest
field?), XkbSendMapNotify, XkbHandleBell and XkbSendActionMessage.
It seems clear from the naming (kbd) of the DeviceIntPtr parameter in
those cases that above functions are intended to be called only for regular
keyboard devices? Is this guaranteed?
Cheers,
Magnus
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
xinput test crashes server when touchpad clicked
With the latest server and synaptics driver from git I can reliably crash
the server by starting
xinput test SynPS2/2 Synaptics Touchpad
and then clicking the any of the physical buttons or tapping the pad to
simulate a click.
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0x7f808f66b6f0 (LWP 22831)]
XkbFilterEvents (pClient=0x46d2e80, nEvents=1, xE=0x45b5580) at
xkbEvents.c:822
/usr/src/debug/x11-base/xorg-server-/xorg-
server-/xkb/xkbEvents.c:822:23919:beg:0x554d35
(gdb) backtrace
#0 XkbFilterEvents (pClient=0x46d2e80, nEvents=1, xE=0x45b5580) at
xkbEvents.c:822
#1 0x004505ad in WriteEventsToClient (pClient=0x46d2e80, count=1,
events=0x45b5580) at events.c:5938
#2 0x004546c5 in TryClientEvents (client=0x46d2e80, dev=value
optimized out, pEvents=0x45b5580, count=1, mask=2540292784,
filter=41155024, grab=0x0) at events.c:1985
#3 0x0045532c in DeliverEventsToWindow (pDev=0x2ac7d40,
pWin=0x27b42f0, pEvents=0x45b5580, count=1, filter=4, grab=0x0, mskidx=2) at
events.c:2122
#4 0x00456f25 in DeliverDeviceEvents (pWin=0x27b42f0, xE=0x45b5580,
grab=0x0, stopAt=0x0, dev=0x2ac7d40, count=1) at events.c:2420
#5 0x00537ecd in ProcessOtherEvent (xE=0x45b5580, device=0x2ac7d40,
count=1) at exevents.c:1126
#6 0x005603cd in ProcessKeyboardEvent (xE=0x45b5580,
keybd=0x2ac7d40, count=1) at xkbPrKeyEv.c:208
#7 0x004cd11c in mieqProcessInputEvents () at mieq.c:378
#8 0x00490669 in ProcessInputEvents () at xf86Events.c:174
#9 0x0044ae21 in Dispatch () at dispatch.c:363
#10 0x00430f3d in main (argc=9, argv=0x7fff9769d128, envp=value
optimized out) at main.c:384
The server dies because of a null pointer in
Bool
XkbFilterEvents(ClientPtr pClient,int nEvents,xEvent *xE)
{
int i, button_mask;
DeviceIntPtr pXDev = inputInfo.keyboard;
XkbSrvInfoPtr xkbi;
if (xE-u.u.type EXTENSION_EVENT_BASE)
{
pXDev = XIGetDevice(xE);
if (!pXDev)
pXDev = inputInfo.keyboard;
}
xkbi= pXDev-key-xkbInfo;
^
| key is NULL on crash
Why would a touchpad be treated as a keyboard here?
Regards,
Magnus Kessler
signature.asc
Description: This is a digitally signed message part.
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Synaptics patch: orientation
On Tuesday 11 November 2008, Mildred Ki'Lya wrote: Hi, Le Tue 11/11/2008 à 15:21 Éric Piel à écrit: The next thing would be to automatically change the orientation of the trackpad when XRandR rotates the screen. Certainly not at the X server level. I have two screens, which screen's orientation are you going to use? However, at a higher level, like in the gnome applet for screen resolution, that would be very useful. I was thinking at a higher level (like the gnome applet). But why not at the lower level (if specifically allowed in xorg.conf). The screen that would be monitored would be of course the laptop's screen (LVDS for me). Well, I guess that if you have a trackpad it's on a laptop, right? Not necessarily ;). I for one have been using a number of desktop keyboards with a built-in touchpad over the years. Alternatively there are stand-alone touchpads on the market as well. Magnus :) Mildred ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] Ansification of libICE
Please find attached a patch that makes libICE ANSI C compliant and fixes a
few small type related issues flagged by gcc and sparse.
Best Regards,
Magnus Kessler
Ansify libICE
Ansify libICE and fix some type issues flagged by sparse and gcc
Signed-off-by: Magnus Kessler [EMAIL PROTECTED]
diff --git a/src/ICElibint.h b/src/ICElibint.h
index ca61553..5880241 100644
--- a/src/ICElibint.h
+++ b/src/ICElibint.h
@@ -37,6 +37,7 @@ Author: Ralph Mor, X Consortium
#include X11/ICE/ICEproto.h
#include X11/ICE/ICEconn.h
#include X11/ICE/ICEmsg.h
+#include X11/ICE/ICEutil.h
#ifdef WIN32
#include X11/Xwindows.h
#endif
@@ -410,6 +411,9 @@ extern _IceWatchProc *_IceWatchProcs;
extern IceErrorHandler _IceErrorHandler;
extern IceIOErrorHandler _IceIOErrorHandler;
+extern int _IcePaAuthDataEntryCount;
+extern IceAuthDataEntry _IcePaAuthDataEntries[];
+
extern void _IceErrorBadMajor (
IceConn /* iceConn */,
@@ -537,4 +541,51 @@ extern void _IceGetPaValidAuthIndices (
int * /* indices_ret */
);
+extern void _IceDefaultErrorHandler (
+IceConn /* iceConn*/,
+Bool /* swap */,
+int /* offendingMinorOpcode */,
+unsigned long /* offendingSequence */,
+int /* errorClass */,
+int /* severity */,
+IcePointer /* values */
+);
+
+extern void _IceDefaultIOErrorHandler (
+IceConn /* iceConn */
+);
+
+extern IcePoAuthStatus _IcePoMagicCookie1Proc (
+IceConn /* iceConn */,
+IcePointer * /* authStatePtr */,
+Bool /* cleanUp */,
+Bool /* swap */,
+int /* authDataLen */,
+IcePointer /* authData */,
+int * /* replyDataLenRet */,
+IcePointer * /* replyDataRet */,
+char ** /* errorStringRet */
+);
+
+extern IcePaAuthStatus _IcePaMagicCookie1Proc(
+IceConn /* iceConn */,
+IcePointer * /* authStatePtr */,
+Bool /* swap */,
+int /* authDataLen */,
+IcePointer /* authData */,
+int * /* replyDataLenRet */,
+IcePointer * /* replyDataRet */,
+char ** /* errorStringRet */
+);
+
+extern void _IceProcessCoreMessage(
+IceConn /* iceConn */,
+int /* opcode */,
+unsigned long /* length */,
+Bool /* swap */,
+IceReplyWaitInfo * /* replyWait */,
+Bool * /* replyReadyRet */,
+Bool * /* connectionClosedRet */
+);
+
#endif /* _ICELIBINT_H_ */
diff --git a/src/accept.c b/src/accept.c
index d54ffd4..e883029 100644
--- a/src/accept.c
+++ b/src/accept.c
@@ -36,11 +36,7 @@ Author: Ralph Mor, X Consortium
IceConn
-IceAcceptConnection (listenObj, statusRet)
-
-IceListenObj listenObj;
-IceAcceptStatus *statusRet;
-
+IceAcceptConnection (IceListenObj listenObj, IceAcceptStatus *statusRet)
{
IceConn iceConn;
XtransConnInfo newconn;
@@ -51,7 +47,7 @@ IceAcceptStatus *statusRet;
* Accept the connection.
*/
-if ((newconn = _IceTransAccept (listenObj-trans_conn, status)) == 0)
+if ((newconn = _IceTransAccept (listenObj-trans_conn, status)) == NULL)
{
if (status == TRANS_ACCEPT_BAD_MALLOC)
*statusRet = IceAcceptBadMalloc;
diff --git a/src/authutil.c b/src/authutil.c
index 9cb3deb..3bfa324 100755
--- a/src/authutil.c
+++ b/src/authutil.c
@@ -72,7 +72,6 @@ static Status write_counted_string (FILE *file, unsigned short count, char *stri
char *
IceAuthFileName (void)
-
{
static char slashDotICEauthority[] = /.ICEauthority;
char *name;
@@ -138,15 +137,8 @@ IceAuthFileName (void)
}
-
int
-IceLockAuthFile (file_name, retries, timeout, dead)
-
-char *file_name;
-int retries;
-int timeout;
-long dead;
-
+IceLockAuthFile (char *file_name, int retries, int timeout, long dead)
{
char creat_name[1025], link_name[1025];
struct stat statb;
@@ -215,12 +207,8 @@ long dead;
}
-
void
-IceUnlockAuthFile (file_name)
-
-char *file_name;
-
+IceUnlockAuthFile (char *file_name)
{
#ifndef WIN32
char creat_name[1025];
@@ -244,12 +232,8 @@ char *file_name;
}
-
IceAuthFileEntry *
-IceReadAuthFileEntry (auth_file)
-
-FILE *auth_file;
-
+IceReadAuthFileEntry (FILE *auth_file)
{
IceAuthFileEntry local;
IceAuthFileEntry *ret;
@@ -296,12 +280,8 @@ FILE *auth_file;
}
-
void
-IceFreeAuthFileEntry (auth)
-
-IceAuthFileEntry *auth;
-
+IceFreeAuthFileEntry (IceAuthFileEntry *auth)
{
if (auth)
{
@@ -315,13 +295,8 @@ IceAuthFileEntry *auth;
}
-
Status
-IceWriteAuthFileEntry (auth_file, auth)
-
-FILE *auth_file;
-IceAuthFileEntry *auth;
-
+IceWriteAuthFileEntry (FILE *auth_file, IceAuthFileEntry *auth)
{
if (!write_string (auth_file, auth-protocol_name))
return (0);
@@ -344,14 +319,8 @@ IceAuthFileEntry *auth;
}
-
IceAuthFileEntry *
-IceGetAuthFileEntry (protocol_name, network_id, auth_name)
-
-char *protocol_name;
-char *network_id;
-char *auth_name;
-
+IceGetAuthFileEntry (char *protocol_name, char *network_id, char *auth_name)
{
FILE *auth_file;
char *filename;
@@ -387,7 +356,6 @@ char *auth_name;
}
-
/*
* local routines
XCB compilation failure with socket handoff patch (was Re: compilation failure)
On Thursday 23 October 2008, Beso wrote: i also have the following error on libxcb: [...] xcb_out.c: In function 'get_socket_back': xcb_out.c:61: error: '_xcb_out' has no member named 'return_socket' xcb_out.c:61: error: '_xcb_out' has no member named 'socket_moving' xcb_out.c:62: error: '_xcb_out' has no member named 'socket_cond' xcb_out.c:63: error: '_xcb_out' has no member named 'return_socket' xcb_out.c:66: error: '_xcb_out' has no member named 'socket_moving' xcb_out.c:68: error: '_xcb_out' has no member named 'return_socket' xcb_out.c:68: error: '_xcb_out' has no member named 'socket_closure' xcb_out.c:70: error: '_xcb_out' has no member named 'socket_moving' xcb_out.c:72: error: '_xcb_out' has no member named 'socket_cond' xcb_out.c:73: error: '_xcb_out' has no member named 'return_socket' xcb_out.c:74: error: '_xcb_out' has no member named 'socket_closure' xcb_out.c: In function 'xcb_take_socket': xcb_out.c:270: error: '_xcb_out' has no member named 'return_socket' xcb_out.c:271: error: '_xcb_out' has no member named 'socket_closure' xcb_out.c: In function '_xcb_out_init': xcb_out.c:308: error: '_xcb_out' has no member named 'socket_cond' xcb_out.c:310: error: '_xcb_out' has no member named 'return_socket' xcb_out.c:311: error: '_xcb_out' has no member named 'socket_closure' xcb_out.c:312: error: '_xcb_out' has no member named 'socket_moving' make[2]: *** [xcb_out.lo] Error 1 Hi Beso, you seem to be using the Gentoo x11 overlay, which is applying a version of the socket handoff patch. Since commit cebd582a (allow compile-time setting for XCB queue buffer size) the patch that adds the missing members to _xcb_out is applied in the wrong place, namely the _xcb_in structure. You can fix this by changing a line in xcb-0004-Support-handing-off-socket-write-permission-to-exter.patch. Look for char queue[4096]; and change to char queue[XCB_QUEUE_BUFFER_SIZE]; I'm cross-posting this to the xcb mailing list as well as the issue affects the recently posted version 3 of the patchset as well. Cheers, Magnus signature.asc Description: This is a digitally signed message part. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Transfer display of active windows remotely
On Saturday 11 October 2008, Prasad H.L. wrote: This is what I have in mind. - Consider display :0 on machine 1 (m1) and display :0 on machine 2 (m2). - Let us say, a process 'p1' running under privileges of user 'u' opens a window on :0 of m1. - I do an 'ssh -X [EMAIL PROTECTED]' in xterm on :0 of m2 and login to m1. - Now, from that xterm window, is there any way by which I can make that window of process 'p1' appear on :0 of m2. This kind of situation regularly occurs to me and some of my friends. We have multiple terminals at our disposal. On one terminal, I start some xterm which is, let us say, showing output of some process. I go to some other department in the institute and do an ssh to that terminal. Now, I have no way of seeing what is going on in that xterm. Well, this is a simple example, of course. This particular use case, seeing the terminal output of a process on a different terminal, can be achieved quite easily using screen [0]. No support from X required at all. In a first terminal (or even on the console without any X) run screen. Then run any non-graphical process in the screen session. When you move to a different computer, log into the first one through ssh and grab the screen session (screen -dr). You will see the output of the still running process there. Another example (though childish). Consider a case where I have a browser window with many tabs open in it, the window being displayed on :0 of m1. I would like to export it to :0 of m2 when I go and sit in front of m2. Before closing ssh on m2, I re-export the window back to :0 of m1 and then quit the ssh. Such a feature would be really great to have. Since, any way, currently the only dependency on the remote machine is that it should have an X server running, I believe this feature should be implementable if not already present. Have you looked into NX [1]? NX can be considered the screen for running X sessions. I usually run an NX session on one machine (in the background, without any access to the graphics hardware), then connect to it using the nxclient software from either machine on the network. I can disconnect from a running session and pick it up later from somewhere else. With Regards, Prasad H. L. Hope this helps. Best Regards, Magnus Kessler [0] http://www.gnu.org/software/screen/ [1] http://www.nomachine.com/ signature.asc Description: This is a digitally signed message part. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Minimum version of XInput API?
Hi, what's considered the minimum version of the XInput ABI an input driver needs to support these days? I see lots of #if GET_ABI_MAJOR in the xf86-input-synaptics driver that seem to support ancient ABI versions. Is this still appropriate? Regards, Magnus Kessler signature.asc Description: This is a digitally signed message part. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] xf86-input-synaptics janitorial patches
Hi,
here are a few janitorial patches for the synaptics driver. The patches to
the tools directory eliminate warnings flagged up by sparse. The patch to
the driver code reduces the dependency on the mi code, which only needed to
support an ancient XInput ABI version.
Regards,
Magnus Kessler
[sparse] Fix warnings about using plain integer as NULL pointer
Signed-off-by: Magnus Kessler [EMAIL PROTECTED]
diff --git a/tools/synclient.c b/tools/synclient.c
index f9e4330..2677d63 100644
--- a/tools/synclient.c
+++ b/tools/synclient.c
@@ -123,7 +123,7 @@ static struct Parameter params[] = {
DEFINE_PAR(PressureMotionMinFactor, press_motion_min_factor, PT_DOUBLE, 0, 10.0),
DEFINE_PAR(PressureMotionMaxFactor, press_motion_max_factor, PT_DOUBLE, 0, 10.0),
DEFINE_PAR(GrabEventDevice, grab_event_device, PT_BOOL, 0, 1),
-{ 0, 0, 0, 0, 0 }
+{ NULL, 0, 0, 0, 0 }
};
static void
diff --git a/tools/syndaemon.c b/tools/syndaemon.c
index 8fd958b..7aa8238 100644
--- a/tools/syndaemon.c
+++ b/tools/syndaemon.c
@@ -113,7 +113,7 @@ install_signal_handler(void)
#endif
for (i = 0; i sizeof(signals) / sizeof(int); i++) {
- if (sigaction(signals[i], act, 0) == -1) {
+ if (sigaction(signals[i], act, NULL) == -1) {
perror(sigaction);
exit(2);
}
[sparse] Fix warnings about non-ANSI function declarations
Signed-off-by: Magnus Kessler [EMAIL PROTECTED]
diff --git a/tools/synclient.c b/tools/synclient.c
index 7977d89..f9e4330 100644
--- a/tools/synclient.c
+++ b/tools/synclient.c
@@ -240,7 +240,7 @@ is_equal(SynapticsSHM *s1, SynapticsSHM *s2)
}
static double
-get_time()
+get_time(void)
{
struct timeval tv;
gettimeofday(tv, NULL);
@@ -285,7 +285,7 @@ monitor(SynapticsSHM *synshm, int delay)
}
static void
-usage()
+usage(void)
{
fprintf(stderr, Usage: synclient [-m interval] [-h] [-l] [-V] [-?] [var1=value1 [var2=value2] ...]\n);
fprintf(stderr, -m monitor changes to the touchpad state.\n
diff --git a/tools/syndaemon.c b/tools/syndaemon.c
index 9e3ad98..8fd958b 100644
--- a/tools/syndaemon.c
+++ b/tools/syndaemon.c
@@ -52,7 +52,7 @@ static const char *pid_file;
static unsigned char keyboard_mask[KEYMAP_SIZE];
static void
-usage()
+usage(void)
{
fprintf(stderr, Usage: syndaemon [-i idle-time] [-m poll-delay] [-d] [-t] [-k]\n);
fprintf(stderr, -i How many seconds to wait after the last key press before\n);
@@ -68,7 +68,7 @@ usage()
}
static int
-enable_touchpad()
+enable_touchpad(void)
{
int ret = 0;
if (pad_disabled) {
@@ -89,7 +89,7 @@ signal_handler(int signum)
}
static void
-install_signal_handler()
+install_signal_handler(void)
{
static int signals[] = {
SIGHUP, SIGINT, SIGQUIT, SIGILL, SIGTRAP, SIGABRT,
@@ -156,7 +156,7 @@ keyboard_activity(Display *display)
* Return non-zero if any physical touchpad button is currently pressed.
*/
static int
-touchpad_buttons_active()
+touchpad_buttons_active(void)
{
int i;
@@ -171,7 +171,7 @@ touchpad_buttons_active()
}
static double
-get_time()
+get_time(void)
{
struct timeval tv;
gettimeofday(tv, NULL);
Only include mipointer.h if supporting ancient XInput ABI version
Signed-off-by: Magnus Kessler [EMAIL PROTECTED]
diff --git a/src/synaptics.c b/src/synaptics.c
index 4b3a022..50bb6de 100644
--- a/src/synaptics.c
+++ b/src/synaptics.c
@@ -66,9 +66,12 @@
#include stdio.h
#include xf86_OSproc.h
#include xf86Xinput.h
-#include mipointer.h
#include exevents.h
+#if GET_ABI_MAJOR(ABI_XINPUT_VERSION) == 0
+#include mipointer.h
+#endif
+
#include synaptics.h
#include synapticsstr.h
#include synaptics-properties.h
signature.asc
Description: This is a digitally signed message part.
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] RFC: remove support for XInput ABI 0.x from xf86-input-synaptics driver
This series of patches removes support for the ancient XInput ABI 0.x from
the synaptics driver, which in turn makes some more cleanup patches
possible. There seems to be a consensus that supporting XInput ABI older
than 2.x is not really needed any more [1].
Caveat: do we need some changes to the configure script to detect building
against a very old X server?
Cheers,
Magnus
[1] http://lists.freedesktop.org/archives/xorg/2008-October/039276.html
Remove support for XInput ABI 0.x
Signed-off-by: Magnus Kessler [EMAIL PROTECTED]
diff --git a/src/synaptics.c b/src/synaptics.c
index 50bb6de..0286af8 100644
--- a/src/synaptics.c
+++ b/src/synaptics.c
@@ -68,10 +68,6 @@
#include xf86Xinput.h
#include exevents.h
-#if GET_ABI_MAJOR(ABI_XINPUT_VERSION) == 0
-#include mipointer.h
-#endif
-
#include synaptics.h
#include synapticsstr.h
#include synaptics-properties.h
@@ -531,10 +527,6 @@ SynapticsPreInit(InputDriverPtr drv, IDevPtr dev, int flags)
local-private_flags = 0;
local-flags = XI86_POINTER_CAPABLE | XI86_SEND_DRAG_EVENTS;
local-conf_idev = dev;
-#if GET_ABI_MAJOR(ABI_XINPUT_VERSION) == 0
-local-motion_history_proc = xf86GetMotionEvents;
-local-history_size= 0;
-#endif
local-always_core_feedback= 0;
xf86Msg(X_INFO, Synaptics touchpad driver version %s\n, PACKAGE_VERSION);
@@ -585,10 +577,6 @@ SynapticsPreInit(InputDriverPtr drv, IDevPtr dev, int flags)
goto SetupProc_fail;
}
-#if GET_ABI_MAJOR(ABI_XINPUT_VERSION) == 0
-local-history_size = xf86SetIntOption(opts, HistorySize, 0);
-#endif
-
xf86ProcessCommonOptions(local, local-options);
local-flags |= XI86_CONFIGURED;
@@ -760,17 +748,11 @@ DeviceInit(DeviceIntPtr dev)
InitPointerDeviceStruct((DevicePtr)dev, map,
SYN_MAX_BUTTONS,
-#if GET_ABI_MAJOR(ABI_XINPUT_VERSION) == 0
- miPointerGetMotionEvents,
-#elif GET_ABI_MAJOR(ABI_XINPUT_VERSION) 3
+#if GET_ABI_MAJOR(ABI_XINPUT_VERSION) 3
GetMotionHistory,
#endif
SynapticsCtrl,
-#if GET_ABI_MAJOR(ABI_XINPUT_VERSION) == 0
- miPointerGetMotionBufferSize()
-#else
GetMotionHistorySize(), 2
-#endif
);
/* X valuator */
if (priv-minx priv-maxx)
@@ -785,10 +767,6 @@ DeviceInit(DeviceIntPtr dev)
xf86InitValuatorAxisStruct(dev, 1, 0, -1, 1, 0, 1);
xf86InitValuatorDefaults(dev, 1);
-#if GET_ABI_MAJOR(ABI_XINPUT_VERSION) == 0
-xf86MotionHistoryAllocate(local);
-#endif
-
if (!alloc_param_data(local))
return !Success;
Remove all uses of DBG macro.
DBG macro was only supported with XInput ABI 0.x
Signed-off-by: Magnus Kessler [EMAIL PROTECTED]
diff --git a/src/synaptics.c b/src/synaptics.c
index 0286af8..36c510b 100644
--- a/src/synaptics.c
+++ b/src/synaptics.c
@@ -97,10 +97,6 @@ typedef enum {
#define M_SQRT1_2 0.70710678118654752440 /* 1/sqrt(2) */
#endif
-#if GET_ABI_MAJOR(ABI_XINPUT_VERSION) = 1
-#define DBG(a,b)
-#endif
-
/*
* Forward declaration
/
@@ -570,8 +566,6 @@ SynapticsPreInit(InputDriverPtr drv, IDevPtr dev, int flags)
goto SetupProc_fail;
priv-comm.buffer = XisbNew(local-fd, 200);
-DBG(9, XisbTrace(priv-comm.buffer, 1));
-
if (!QueryHardware(local)) {
xf86Msg(X_ERROR, %s Unable to query/initialize Synaptics hardware.\n, local-name);
goto SetupProc_fail;
@@ -626,15 +620,6 @@ static void SynapticsUnInit(InputDriverPtr drv,
static void
SynapticsCtrl(DeviceIntPtr device, PtrCtrl *ctrl)
{
-DBG(3, ErrorF(SynapticsCtrl called.\n));
-/*
- pInfo = device-public.devicePrivate;
- pMse = pInfo-private;
-
- pMse-num = ctrl-num;
- pMse-den = ctrl-den;
- pMse-threshold = ctrl-threshold;
-*/
}
static Bool
@@ -668,8 +653,6 @@ DeviceOn(DeviceIntPtr dev)
LocalDevicePtr local = (LocalDevicePtr) dev-public.devicePrivate;
SynapticsPrivate *priv = (SynapticsPrivate *) (local-private);
-DBG(3, ErrorF(Synaptics DeviceOn called\n));
-
SetDeviceAndProtocol(local);
local-fd = xf86OpenSerial(local-options);
if (local-fd == -1) {
@@ -702,8 +685,6 @@ DeviceOff(DeviceIntPtr dev)
LocalDevicePtr local = (LocalDevicePtr) dev-public.devicePrivate;
SynapticsPrivate *priv = (SynapticsPrivate *) (local-private);
-DBG(3, ErrorF(Synaptics DeviceOff called\n));
-
if (local-fd != -1) {
TimerFree(priv-timer);
priv-timer = NULL;
@@ -739,8 +720,6 @@ DeviceInit(DeviceIntPtr dev)
unsigned char map[SYN_MAX_BUTTONS + 1];
int i;
-DBG(3, ErrorF(Synaptics DeviceInit called\n));
-
for (i = 0; i = SYN_MAX_BUTTONS; i++)
map[i] = i;
@@ -1101,33 +1080,26 @@ SelectTapButton(SynapticsPrivate *priv, edge_type edge)
default:
switch (edge) {
case RIGHT_TOP_EDGE:
- DBG(7, ErrorF(right top edge\n));
tap = RT_TAP
[PATCH] various xf86-input-synaptics cleanups
Following on from the recent removal of the repeater fifo from the synaptics
driver, these 3 patches clean up the code a bit:
01-synaptics-queryhardware-controlflow.diff simplifies the QueryHardware
function a bit.
02-synaptics-queryhardware-message.diff reintroduces a message that informs
the user that this driver cannot deal with the hardware for which it was
configured.
03-synaptics-remove-unused.diff removes an unused #define and some #includes
that were previously required for the fifo functionality.
Best Regards,
Magnus
Clean up control-flow
Signed-off-by: Magnus Kessler [EMAIL PROTECTED]
diff --git a/src/synaptics.c b/src/synaptics.c
index 148b3f6..8a6aeb7 100644
--- a/src/synaptics.c
+++ b/src/synaptics.c
@@ -2186,10 +2186,10 @@ QueryHardware(LocalDevicePtr local)
if (priv-proto_ops-QueryHardware(local, priv-synhw)) {
para-synhw = priv-synhw;
- return TRUE;
+} else {
+ priv-proto_ops-DeviceOffHook(local);
}
-priv-proto_ops-DeviceOffHook(local);
return TRUE;
}
Re-introduce message about unsupported touchpad that was dropped with the
repeater device removal.
Signed-off-by: Magnus Kessler [EMAIL PROTECTED]
diff --git a/src/synaptics.c b/src/synaptics.c
index 8a6aeb7..c1db1d2 100644
--- a/src/synaptics.c
+++ b/src/synaptics.c
@@ -2187,6 +2187,7 @@ QueryHardware(LocalDevicePtr local)
if (priv-proto_ops-QueryHardware(local, priv-synhw)) {
para-synhw = priv-synhw;
} else {
+ xf86Msg(X_PROBED, %s: no supported touchpad found\n, local-name);
priv-proto_ops-DeviceOffHook(local);
}
Remove unused defines and includes
Signed-off-by: Magnus Kessler [EMAIL PROTECTED]
diff --git a/src/synaptics.c b/src/synaptics.c
index c1db1d2..4b3a022 100644
--- a/src/synaptics.c
+++ b/src/synaptics.c
@@ -59,15 +59,10 @@
#endif
#include unistd.h
-#include sys/ioctl.h
#include misc.h
#include xf86.h
#include sys/shm.h
-#include sys/ipc.h
-#include sys/stat.h
-#include errno.h
#include math.h
-#include unistd.h
#include stdio.h
#include xf86_OSproc.h
#include xf86Xinput.h
@@ -92,7 +87,6 @@ typedef enum {
#define MAX(a, b) (((a)(b))?(a):(b))
#define MIN(a, b) (((a)(b))?(a):(b))
#define TIME_DIFF(a, b) ((int)((a)-(b)))
-#define SYSCALL(call) while (((call) == -1) (errno == EINTR))
#define SQR(x) ((x) * (x))
signature.asc
Description: This is a digitally signed message part.
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] xf86-input-synaptics: fix creation of repeater fifo
On Monday 29 September 2008, Peter Hutterer wrote: On Sun, Sep 28, 2008 at 03:11:46PM +0100, Magnus Kessler wrote: Testing status against EEXIST is wrong and we should check errno instead if we want to allow the use of an existing file. However, since we pass a file name that in principle could be any existing file (not just fifos) is there any guarantee that we can later actually use the fifo? Thanks. There is no guarantee that we can use it, but at the same time the use-case where the pipe already exists is common. In the simple case of a server restart, the first mkfifo command succeeds but the second fails with EEXIST. So the pipe is still there and should be used. Admittedly, it might be a good idea to clean up after ourselves and delete the fifo if we have created it in the first place. What about the (compile-tested) code below? Cheers, Peter [patch snipped] Hi Peter, your patch would certainly work and prevent fifos created by the driver hang around if and when the X server terminated normally. Crashes would still lead to the current situation. I'm also slightly nervous about adding yet more code to functionality that is effectively never used in normal operations. New proposal to follow... Cheers, Magnus signature.asc Description: This is a digitally signed message part. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Extra pointer motion with current git xf86-input-synaptics
On Sunday 28 September 2008, Peter Hutterer wrote: On Sat, Sep 27, 2008 at 06:10:32PM +0100, Magnus Kessler wrote: Since updating to the current git version of xorg-server, inputproto and xf86-input-synaptics I observe extra pointer movements for every event generated by the touchpad. Even when not touching the pad and using the buttons instead the pointer moves 1 pixel to the top-left which each event (x and y coordinate decrease by 1 every time). Equally, each event generated from touching the pad seems to have this extra movement towards the top-left of the screen. what hardware do you have? Any special options in xorg.conf/the fdi file? Cheers, Peter This is with an external mini-keyboard with built-in touchpad. Dmesg reports it as Synaptics Touchpad, model: 1, fw: 4.1, id: 0x14aa1, caps: 0x0/0x0 and in Xorg.0.log the xf86-input-synaptics driver reports (**) Option Device /dev/input/event1 (II) SynPS/2 Synaptics TouchPad: x-axis range 1472 - 5472 (II) SynPS/2 Synaptics TouchPad: y-axis range 1408 - 4448 (II) SynPS/2 Synaptics TouchPad: pressure range 0 - 255 (II) SynPS/2 Synaptics TouchPad: finger width range 0 - 0 (II) SynPS/2 Synaptics TouchPad: buttons: left right middle double triple (**) Option SHMConfig 1 (**) Option VertEdgeScroll 1 (**) Option HorizEdgeScroll 1 (**) Option LockedDrags 0 (**) Option TapButton1 1 (**) Option PalmDetect yes The fdi file I'm using is ?xml version=1.0 encoding=ISO-8859-1? deviceinfo version=0.2 device match key=info.capabilities contains=input.touchpad match key=info.product contains=Synaptics TouchPad merge key=input.x11_driver type=stringsynaptics/merge merge key=input.x11_options.Emulate3Buttons type=stringyes/merge merge key=input.x11_options.LockedDrags type=string0/merge merge key=input.x11_options.PalmDetect type=stringyes/merge merge key=input.x11_options.CoastingSpeed type=string20/merge merge key=input.x11_options.TapButton1 type=string1/merge merge key=input.x11_options.VertEdgeScroll type=string1/merge merge key=input.x11_options.HorizEdgeScroll type=string1/merge merge key=input.x11_options.SHMConfig type=string1/merge /match /match /device /deviceinfo I have just reverted the part of commit c405a69f83dab77cfe6c76f718a3ca5614a85918 that passes the actual x/y ranges to xf86InitValuatorAxisStruct. Now the extra movement is gone, but I get a somewhat quicker cursor movement than I was used to before. This would be due to the other recent changes that set new default values for the acceleration parameters, of course. I'm trying to see where in the valuators are actually used inside the X server. With a smaller range than [0, -1] some rounding error (?) seems to create that extra pixel offset for each event processed. This is on a 64-bit platform, in case this is important. Any hints on where to look next are welcome. Cheers, Magnus signature.asc Description: This is a digitally signed message part. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Extra pointer motion with current git xf86-input-synaptics
Since updating to the current git version of xorg-server, inputproto and xf86-input-synaptics I observe extra pointer movements for every event generated by the touchpad. Even when not touching the pad and using the buttons instead the pointer moves 1 pixel to the top-left which each event (x and y coordinate decrease by 1 every time). Equally, each event generated from touching the pad seems to have this extra movement towards the top-left of the screen. Is anyone else experiencing this problem? Best Regards, Magnus Kessler signature.asc Description: This is a digitally signed message part. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
