[no subject]
Hello,
Had 48 hours with no mouse movement since commit
b450efdf95999cad08de23ce069f04a66bdae24b to xorg/driver/xf86-input-evdev
Seems below #endif went one line too far:
>>>
@@ -1136,10 +1141,12 @@ EvdevAddRelValuatorClass(DeviceIntPtr device)
for (axis = REL_X; i < MAX_VALUATORS && axis <= REL_MAX; axis++)
{
pEvdev->axis_map[axis] = -1;
+#ifndef HAVE_SMOOTH_SCROLLING
/* We don't post wheel events, so ignore them here too */
if (axis == REL_WHEEL || axis == REL_HWHEEL || axis == REL_DIAL)
continue;
if (!EvdevBitIsSet(pEvdev->rel_bitmask, axis))
+#endif
continue;
pEvdev->axis_map[axis] = i;
i++;
@@ -1168,6 +1175,14 @@ EvdevAddRelValuatorClass(DeviceIntPtr device)
<<<
Should be:
>>>
+#endif
if (!EvdevBitIsSet(pEvdev->rel_bitmask, axis))
<<<
thanks,
s.
___
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: laptop keyboard is ignored configuration layout from xorg.conf.d since XInput ABI 12
xorg-devel patch is working. Thank s. [PATCH] xfree86: swap the order to-be-merged lists in xf86CollectInputOptions. ___ 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: laptop keyboard is ignored configuration layout from xorg.conf.d since XInput ABI 12
Hi, Oh, forgot to mention the sources are from git tree, the patch is there, same problem again. Thanks, S. > A british laptop layout is not recognized since a couple of weeks with > compilation from git. > > Section "InputClass" > Identifier"AT Keyboard" > > MatchProduct"AT Translated Set 2 keyboard" > MatchIsKeyboard"on" > Driver"evdev" > Option"AutoServerLayout""on" > > Option"AutoRepeat""500 30" > Option"XkbRules""xorg" > > Option"XkbModel""pc104" > Option"XkbLayout""gb" > Option"XkbVariant""basic,winkeys" > EndSection > > What can be done? commit beea2378f142556471c62290e275935af848e137 Author: Peter Hutterer Date: Mon Dec 6 14:33:43 2010 +1000 xfree86: don't overwrite option list (#32115) Options set in the configuration file were unconditionally overwritten by the server. Merge the already existing options and the new options together instead of just overwriting ones. http://bugs.freedesktop.org/show_bug.cgi?id=32115 Cheers, Peter ___ 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
laptop keyboard is ignored configuration layout from xorg.conf.d since XInput ABI 12
Hi, A british laptop layout is not recognized since a couple of weeks with compilation from git. Section "InputClass" Identifier "AT Keyboard" MatchProduct"AT Translated Set 2 keyboard" MatchIsKeyboard "on" Driver "evdev" Option "AutoServerLayout" "on" Option "AutoRepeat""500 30" Option "XkbRules" "xorg" Option "XkbModel" "pc104" Option "XkbLayout" "gb" Option "XkbVariant""basic,winkeys" EndSection What can be done? Thanks, S. ___ 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
XErrorEvent BadAlloc in client from over-the-back window resize
Hi, I have a client (window) which abort() upon BadAlloc sent XError due to resizing the window "over its back" -- either above the top or beyond the left. (xterm, for example, resizes to a very long window in such a case.) Or BadAlloc sounds like a memory problem, and this might well be, since a negative height or width is a very large unsigned value. How can one tell whether the client should be resize its window to a safe width x height, or there is really a memory problem in the server. Thanks, S. ___ 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: XInput device properties ; keymaps service & console switch
Hi,
in /etc/rc.conf there is a shortcut way to limit rc_tty_number to 6, if xdm
console were 7, e.g. (6<7)/
The init.d script "keymaps" uses `kbd_mode' program from
http://freshmeat.net/projects/kbd/.
Its source files `getfd.c' and `kbd_mode.c' use 2 read ioctl's:
ioctl(fd, KDGKBTYPE, &arg)
ioctl(fd, KDGKBMODE, &mode)
and 1 write ioctl:
ioctl(fd, KDSKBMODE, mode)
the macros come from
#define KDGKBTYPE0x4B33/* get keyboard type */
#define KDGKBMODE0x4B44/* gets current keyboard mode */
#define KDSKBMODE0x4B45/* sets current keyboard mode */
also, some other console services ("numlock") use ${rc_tty_number}.
'fd' is passed to `kbd_mode' from "keymaps" init.d script, in a loop from 1 to
${rc_tty_number:-12}, read from /etc/rc.conf; when 'fd' comes from /dev/tty7,
the ioctl's above appear to conflict with some Xorg code; stopping before
/dev/tty7 does the trick, but at a user is demanded some tweaking of
/etc/rc.conf.
Regard s.
> 2.
>
> When I restart keymaps service like this:
>
> u...@localhost ~ $ #eselect rc restart keymaps
> u...@localhost ~ $ /etc/init.d/keymaps restart
>
> then whenever I press:
>
> - F1..12 keys or
> - Alt+F1..12 or
> - the windows key,
>
> whether Control (CTRL) key is pressed or released, it doesn't matter, I get a
> console switch each time.
what does xev say about key presses? is the ctrl key stuck?
Cheers,
Peter
___
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: XInput device properties ; keymaps service & console switch
Hi, two other notes on VT switching: - using a linux livedvd which yields for `Xorg -version' : X.Org X Server 1.6.3.901 (1.6.4 RC 1) Release Date: 2009-8-25 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.29-hardened-r1 x86_64 Build Date: 01 October 2009 04:33:09PM restarting "keymaps" service has *NO* effect to ALT+F2 bound in the desktop environment to present a window to launch commands (CTRL+ALT+F1..12 does VT switching); - launching "fbsplash" as root in xterm (although for nothing) yields the same negative effect of having ALT+F1..12 do VT switch (without CTRL key pressed) for currently `Xorg -version' : X.Org X Server 1.9.0 Release Date: 2010-08-20 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.35-tuxonice-r1 x86_64 [...] Current Operating System: Linux localhost 2.6.35-tuxonice-r3 #3 SMP [...] 2010 x86_64 Kernel command line: [...] dolvm real_root=/dev/mapper/linux-root usbcore.autosuspend=1 pcie_aspm.policy=powersave tpm_tis.itpm=yes acpi_osi=Linux processor.max_cstate=2 [...] snd_hda_intel.power_save=1 quiet init_opts=3 CONSOLE=/dev/tty fbcon=scrollback:256k splash=verbose,theme:tuxonice real_resume=/dev/sda2 resume=swap:/dev/sda2 Build Date: [...] September 2010 [...] What part in the X server source code might be responsible? Thank s. - Original Message ---- From: Peter Hutterer To: Sebastian Glita Cc: xorg@lists.freedesktop.org Sent: Mon, August 23, 2010 2:28:06 AM Subject: Re: XInput device properties ; keymaps service & console switch > 2. > > When I restart keymaps service like this: > > u...@localhost ~ $ #eselect rc restart keymaps > u...@localhost ~ $ /etc/init.d/keymaps restart > > then whenever I press: > > - F1..12 keys or > - Alt+F1..12 or > - the windows key, > > whether Control (CTRL) key is pressed or released, it doesn't matter, I get a > console switch each time. what does xev say about key presses? is the ctrl key stuck? Cheers, Peter ___ 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: XInput device properties ; keymaps service & console switch
Hi, 2. Sorry, it was only F1..F12+ALT and windows key, not just F1..F12. I inserted xev output below, I pressed/released Ctrl a couple of times; then pressed/released the windows key twice: each time I got a VT switch, I used ALT+F7 to switch from console to Xorg back again. Same would happen with ALT+F1..12 or menu key instead of Super_L. It seems Ctrl key is not stuck. Thanks, s. <<< KeyPress event, serial 31, synthetic NO, window 0x501, root 0x150, subw 0x502, time 38536800, (35,29), root:(306,317), state 0x0, keycode 37 (keysym 0xffe3, Control_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 31, synthetic NO, window 0x501, root 0x150, subw 0x502, time 38536863, (35,29), root:(306,317), state 0x4, keycode 37 (keysym 0xffe3, Control_L), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False KeyPress event, serial 31, synthetic NO, window 0x501, root 0x150, subw 0x502, time 38537358, (35,29), root:(306,317), state 0x0, keycode 37 (keysym 0xffe3, Control_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 31, synthetic NO, window 0x501, root 0x150, subw 0x502, time 38537438, (35,29), root:(306,317), state 0x4, keycode 37 (keysym 0xffe3, Control_L), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False VisibilityNotify event, serial 31, synthetic NO, window 0x501, state VisibilityFullyObscured KeyPress event, serial 31, synthetic NO, window 0x501, root 0x150, subw 0x502, time 38538700, (35,29), root:(306,317), state 0x0, keycode 133 (keysym 0xffeb, Super_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 31, synthetic NO, window 0x501, root 0x150, subw 0x502, time 38538707, (35,29), root:(306,317), state 0x40, keycode 133 (keysym 0xffeb, Super_L), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False VisibilityNotify event, serial 31, synthetic NO, window 0x501, state VisibilityPartiallyObscured Expose event, serial 31, synthetic NO, window 0x501, (0,0), width 178, height 10, count 5 Expose event, serial 31, synthetic NO, window 0x501, (0,10), width 10, height 58, count 4 Expose event, serial 31, synthetic NO, window 0x501, (68,10), width 110, height 58, count 3 Expose event, serial 31, synthetic NO, window 0x501, (0,68), width 178, height 106, count 2 Expose event, serial 31, synthetic NO, window 0x501, (1,174), width 176, height 3, count 1 Expose event, serial 31, synthetic NO, window 0x501, (2,177), width 174, height 1, count 0 VisibilityNotify event, serial 31, synthetic NO, window 0x501, state VisibilityFullyObscured MappingNotify event, serial 31, synthetic NO, window 0x0, request MappingKeyboard, first_keycode 8, count 248 KeyPress event, serial 31, synthetic NO, window 0x501, root 0x150, subw 0x502, time 38540632, (35,29), root:(306,317), state 0x0, keycode 133 (keysym 0xffeb, Super_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 31, synthetic NO, window 0x501, root 0x150, subw 0x502, time 38540640, (35,29), root:(306,317), state 0x40, keycode 133 (keysym 0xffeb, Super_L), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False VisibilityNotify event, serial 32, synthetic NO, window 0x501, state VisibilityPartiallyObscured Expose event, serial 32, synthetic NO, window 0x501, (0,0), width 178, height 10, count 5 Expose event, serial 32, synthetic NO, window 0x501, (0,10), width 10, height 58, count 4 Expose event, serial 32, synthetic NO, window 0x501, (68,10), width 110, height 58, count 3 Expose event, serial 32, synthetic NO, window 0x501, (0,68), width 178, height 106, count 2 Expose event, serial 32, synthetic NO, window 0x501, (1,174), width 176, height 3, count 1 Expose event, serial 32, synthetic NO, window 0x501, (2,177), width 174, height 1, count 0 MotionNotify event, serial 32, synthetic NO, window 0x501, root 0x150, subw 0x502, time 38549990, (35,29), root:(306,317), state 0x0, is_hint 0, same_screen YES >>> On Sat, Aug 21, 2010 at 07:31:21AM -0700, Sebastian Glita wrote: > Hi, > > When using CTRL+ALT+F1..12 to switch between consoles and Xorg, it happens >that: > > 1. > > When I do like this: > > u...@localhost ~ $ xinput set-int-prop 'ImPS/2 Generic Wheel Mouse' > 'Device > > Enabled
XInput device properties ; keymaps service & console switch
Hi, When using CTRL+ALT+F1..12 to switch between consoles and Xorg, it happens that: 1. When I do like this: u...@localhost ~ $ xinput set-int-prop 'ImPS/2 Generic Wheel Mouse' 'Device Enabled' 8 0 u...@localhost ~ $ xinput list-props 'ImPS/2 Generic Wheel Mouse' Device 'ImPS/2 Generic Wheel Mouse': Device Enabled (131): 0 and then switch to console (CTRL+ALT+F1) and then back again, I get this: u...@localhost ~ $ xinput list-props 'ImPS/2 Generic Wheel Mouse' Device 'ImPS/2 Generic Wheel Mouse': Device Enabled (131): 1 So the properties' values change betwen console switching. 2. When I restart keymaps service like this: u...@localhost ~ $ #eselect rc restart keymaps u...@localhost ~ $ /etc/init.d/keymaps restart then whenever I press: - F1..12 keys or - Alt+F1..12 or - the windows key, whether Control (CTRL) key is pressed or released, it doesn't matter, I get a console switch each time. Ok, so I get these versions: <<< u...@localhost ~ $ Xorg -version X.Org X Server 1.9.0 Release Date: 2010-08-20 X Protocol Version 11, Revision 0 Build Operating System: Linux 2.6.35-tuxonice x86_64 Gentoo Current Operating System: Linux localhost 2.6.35-tuxonice #1 SMP Fri Aug 20 21:38:27 EEST 2010 x86_64 Kernel command line: auto BOOT_IMAGE=Gentoo2.6 ro root=801 root=/dev/sda1 real_resume=/dev/sda2 resume=swap:/dev/sda2 usbcore.autosuspend=1 intel_iommu=off fb=no quiet CONSOLE=/dev/tty init_opts=3 fbcon=scrollback:256k splash=verbose,theme:tuxonice Build Date: 21 August 2010 06:33:53AM Current version of pixman: 0.19.3 Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. >>> Thanks, appreciate, s. ___ 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: exa/nouveau segfault
The driver is working now, thanks. Sebastian > Could you retry latest xf86-video-nouveau git? > > Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: exa/nouveau segfault
Yes, patch URIs accepted. tx. S. - Original Message From: Maarten Maathuis To: Sebastian Glita Cc: xorg@lists.freedesktop.org Sent: Friday, September 25, 2009 8:12:55 PM Subject: Re: exa/nouveau segfault running xserver git by any chance? Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: exa/nouveau segfault
Hi, Sorry for the delay. Here it is the backtrace. (gdb) bt #0 0x7f1a24e3cae3 in NV50EXACheckTexture (ppict=0x1767a20, pdpict=0x164e4c0, op=3) at nv50_exa.c:482 #1 0x7f1a24e3cc4a in NV50EXACheckComposite (op=3, pspict=0x1767a20, pmpict=0x1767b10, pdpict=0x164e4c0) at nv50_exa.c:739 #2 0x7f1a2338802c in exaTryDriverComposite (op=32 ' ', pSrc=0x1767a20, pMask=0x1767b10, pDst=0x164e4c0, xSrc=1, ySrc=1, xMask=0, yMask=0, xDst=1, yDst=1, width=247, height=4) at exa_render.c:679 #3 0x7f1a23388d94 in exaComposite (op=3 '\003', pSrc=0x1767a20, pMask=0x1767b10, pDst=0x164e4c0, xSrc=1, ySrc=1, xMask=0, yMask=0, xDst=1, yDst=1, width=247, height=4) at exa_render.c:1019 #4 0x004def7d in damageComposite (op=32 ' ', pSrc=0x1767a20, pMask=0x1767b10, pDst=0x164e4c0, xSrc=1, ySrc=1, xMask=0, yMask=, xDst=, yDst=, width=, height=) at damage.c:643 #5 0x004d1aae in ProcRenderComposite (client=0x846d70) at render.c:723 #6 0x004371e4 in Dispatch () at dispatch.c:445 #7 0x004247ea in main (argc=19, argv=0x7fff0c6a0958, envp=) at main.c:285 (gdb) c Continuing. Program received signal SIGABRT, Aborted. 0x7f1a26978f25 in raise () from /lib/libc.so.6 (gdb) bt #0 0x7f1a26978f25 in raise () from /lib/libc.so.6 #1 0x7f1a2697a2c0 in abort () from /lib/libc.so.6 #2 0x0047dc12 in ddxGiveUp () at xf86Init.c:1212 #3 0x00479102 in FatalError (f=0x59f110 "Caught signal %d (%s). Server aborting\n") at log.c:404 #4 0x00475d9d in OsSigHandler (signo=11, sip=0xc, unused=) at osinit.c:156 #5 #6 0x7f1a24e3cae3 in NV50EXACheckTexture (ppict=0x1767a20, pdpict=0x164e4c0, op=3) at nv50_exa.c:482 #7 0x7f1a24e3cc4a in NV50EXACheckComposite (op=3, pspict=0x1767a20, pmpict=0x1767b10, pdpict=0x164e4c0) at nv50_exa.c:739 #8 0x7f1a2338802c in exaTryDriverComposite (op=32 ' ', pSrc=0x1767a20, pMask=0x1767b10, pDst=0x164e4c0, xSrc=1, ySrc=1, xMask=0, yMask=0, xDst=1, yDst=1, width=247, height=4) at exa_render.c:679 #9 0x7f1a23388d94 in exaComposite (op=3 '\003', pSrc=0x1767a20, pMask=0x1767b10, pDst=0x164e4c0, xSrc=1, ySrc=1, xMask=0, yMask=0, xDst=1, yDst=1, width=247, height=4) at exa_render.c:1019 #10 0x004def7d in damageComposite (op=32 ' ', pSrc=0x1767a20, pMask=0x1767b10, pDst=0x164e4c0, xSrc=1, ySrc=1, xMask=0, yMask=, xDst=, yDst=, width=, height=) at damage.c:643 #11 0x004d1aae in ProcRenderComposite (client=0x846d70) at render.c:723 #12 0x004371e4 in Dispatch () at dispatch.c:445 #13 0x004247ea in main (argc=19, argv=0x7fff0c6a0958, envp=) at main.c:285 Appreciate your help, Sebastian - Original Message From: Maarten Maathuis To: Sebastian Glita Cc: xorg@lists.freedesktop.org Sent: Monday, September 14, 2009 3:00:01 PM Subject: Re: exa/nouveau segfault On Mon, Sep 14, 2009 at 12:27 PM, Sebastian Glita wrote: > Hello, > > I use xorg-server/xf86-video-nouveau/nouveau-drm/mesa/libdrmet.al. from > git.freedesktop.org. [A 2-3 days update solved the trouble with console > switching, always restarting Xorg/gdm. Great relief.] > > Since 1-2 weeks ago I keep getting this segfault whenever launching windows > except x11vnc/xterm/mplayer. Also using gtk+/glib from git.gnome.org. > A proper backtrace made with gdb would help, some debug symbols would be useful too, at least for nouveau. Maarten. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
exa/nouveau segfault
Hello, I use xorg-server/xf86-video-nouveau/nouveau-drm/mesa/libdrm et.al. from git.freedesktop.org. [A 2-3 days update solved the trouble with console switching, always restarting Xorg/gdm. Great relief.] Since 1-2 weeks ago I keep getting this segfault whenever launching windows except x11vnc/xterm/mplayer. Also using gtk+/glib from git.gnome.org. Backtrace: 0: /usr/bin/Xorg (xorg_backtrace+0x28) [0x46b5a8] 1: /usr/bin/Xorg (0x40+0x76e65) [0x476e65] 2: /lib/libpthread.so.0 (0x7fc0aeb23000+0xed40) [0x7fc0aeb31d40] 3: /usr/lib/xorg/modules/drivers/nouveau_drv.so (0x7fc0abbde000+0x4552b) [0x7fc0abc2352b] 4: /usr/lib/xorg/modules/libexa.so (0x7fc0aa155000+0xf02c) [0x7fc0aa16402c] 5: /usr/lib/xorg/modules/libexa.so (0x7fc0aa155000+0xfe4d) [0x7fc0aa164e4d] 6: /usr/bin/Xorg (0x40+0xdec9d) [0x4dec9d] 7: /usr/bin/Xorg (0x40+0xd178e) [0x4d178e] 8: /usr/bin/Xorg (0x40+0x37954) [0x437954] 9: /usr/bin/Xorg (0x40+0x24f5a) [0x424f5a] 10: /lib/libc.so.6 (__libc_start_main+0xe6) [0x7fc0ad753a26] 11: /usr/bin/Xorg (0x40+0x24b19) [0x424b19] Segmentation fault at address 0xc Fatal server error: Caught signal 11 (Segmentation fault). Server aborting --- Thanks for any help, S. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: WM stops the X process
Hello, Thanks for replies. To Ben: > Do your symptoms resemble those of Bug #22679? Xorg resets for each login, not only the first. - Original Message From: Michel Dänzer To: Sebastian Glita Cc: xorg@lists.freedesktop.org Sent: Friday, July 10, 2009 9:38:05 AM Subject: Re: WM stops the X process > And there's no information about the crash in the log files? If so, > check the X server process stderr output for information. Checking stderr output goes a step forward. Using startx -- /usr/bin/Xorg -verbose 4 echoes these last lines on 2 computers: nVidia QP: Xorg: pixman-region.c:372: pixman_region_copy: Assertion `pixman_region_selfcheck (src)' failed. XIO: fatal IO error 104 (Verbinding is weggevallen) on X server ":0.0" after 351 requests (286 known processed) with 0 events remaining. login: fatal IO error 104 (Verbinding is weggevallen) or KillClient on X server ":0.0" xterm: fatal IO error 11 (Hulpbron is tijdelijk onbeschikbaar) or KillClient on X server ":0.0" xinit: connection to X server lost. xterm: fatal IO error 104 (Verbinding is weggevallen) or KillClient on X server ":0.0" ATI: Radeon: Xorg: pixman-region.c:372: pixman_region_copy: Assertion `pixman_region_selfcheck (src)' failed. xterm: fatal IO error 11 (Resource temporarily unavailable) or KillClient on X server ":0.0" xterm: fatal IO error 11 (Resource temporarily unavailable) or KillClient on X server ":0.0" XIO: fatal IO error 11 (Resource temporarily unavailable) on X server ":0.0" after 654 requests (589 known processed) with 0 events remaining. xinit: connection to X server lost. Cannot insert more, X keeps resetting even with twm. There is a failed assertion in pixman/pixman-region.c:372. What now? Thanks, S. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
WM stops the X process
Hello, After some updates since last commits to libX11, X resets after a very short period of lo. Using past configuration that launch a ROX session exhibits this behavior. So after removing .xinitrc and .xsession, in this setting where no session commences, an xterm window opens. Launching startfluxbox kills X (because after deleting /var/log/Xorg.log.old, launching X, resetting X and logging anew, the *.old log appears). Launching mwm embellish the xterm window but moving it kills X. Launching twm seems to work a great period of time, but some actions did lead to resetting X again. This happens on two computers: 1. kernel linux-2.6.29-tuxonice-r3; graphics: nVidia Quadro Pro; xorg-server et. al. from git.freedesktop.org/. 2. kernel linux-2.6.31_rc2-tuxonice-head; graphics: ATI Radeon Xpress 1100 200M; all Xorg packages from git.freedesktop.org/, except =x11-base/xorg-server-1.6.2. Quite annoying; while looking for broken files (libraries), no errors. This is serious, practically X is no longer usable. Thanks for any help, S. PS: Some extra problems: mesa needs correction in: radeon_cs_space_check in src/gallium/winsys/drm/radeon/core/radeon_r300.c (line #66). xf86-video-ati in src/radeon_dri2.c is using a missing "->format" field (line #171). xf86-video-ati in src/radeon_probe.c is missing a #define _XF86DRI_SERVER_ (line #51). xf86-video-nouveau has also some problems with dri2 CreateBuffers/DestroyBuffers (should be singular) (lines #202-203). ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: text characters scrambled with xrandr and qt-4
Tx, I had indeed not enabled VRGB via `eselect fontconfig`; did also so via `rox-font`, but that didn't affect qt. However, I can rotate normal, launch a qt application, then rotate left: this works. Since KDE is not running, configuring QT>=4.5 is out of my hands (qtconfig seems limited). http://www.qtsoftware.com/developer/task-tracker/index_html?method=advsearch&searchstr=subpixel&bugs=on&sugs=on&product=1&functionalarea=486&versionfound=&versionfixed=&priority=-1&status=-1&resolution=-1 http://forum.kde.org/printthread.php?tid=11298 http://labs.trolltech.com/blogs/2008/09/01/subpixel-antialiasing-on-x11/ Seba - Original Message From: Behdad Esfahbod To: Adam Goode Cc: Sebastian Glita ; xorg@lists.freedesktop.org Sent: Friday, March 6, 2009 9:18:13 PM Subject: Re: text characters scrambled with xrandr and qt-4 Adam Goode wrote: > Behdad Esfahbod wrote: >> Sebastian Glita wrote: >>> Hi, >>> >>> Maybe this is a qt-4 problem, but here it is: >>> when: >>> >>> xrandr --output LVDS --rotate left >>> >>> and launch a QT (ver. >=4) application text is scrambled: a multicoloured >>> 20% first line each character. >> Sounds like subpixel filtering using the wrong RGB order. Which isn't >> surprising given that you didn't change the RGB order to VRGB (or VBGR). I'm >> not sure how Qt picks that up other than fontconfig config files. GNOME uses >> XSETTINGS to propagate such things. >> > > I have also noticed this problem, and I did set to VRGB. I didn't > realize it was related to xrandr. Time to file bugs somewhere? Filed for GNOME: http://bugzilla.gnome.org/show_bug.cgi?id=574413 > Adam > ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
text characters scrambled with xrandr and qt-4
Hi, Maybe this is a qt-4 problem, but here it is: when: xrandr --output LVDS --rotate left and launch a QT (ver. >=4) application text is scrambled: a multicoloured 20% first line each character. Thanks, Seba ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: evdev: keyboard or mouse?
Hi,
xinput --reattach did the trick.
I didn't see the messages "configure as mouse/keyboard/..." as *additive*, so I
thought only one must occur.
But can one "filter" the device so that it is exactly and only a pointer? Or
the reverse?
Ι rewrote a little EvdevProbe's find/configure chain. (including the last
has_scroll commit)
First it goes "dry-run" to detect what can be configured.
If option UseAsPointing is true (can only be from user), it tries to
disregard, in the following, the keys, unless UseAsKeyboard is true as
well.
The same holds for option UseAsKeyboard.
If they are not specified, then there is a normal behavior, covering
any capability and naming as keyboard (so KEYBOARD is sort of like KEYPANEL).
Then it configures what was totally discovered, excluding the what
specifically was *not* requested. It's a simple
auto-include&user-exclude mechanism.
The code is also somehow clearer of what it does, separating the stages: you
can easily track the *additive* style in the end.
It is of course redundant. But it answers the intuitive shallow
question regarding these situations. For me, I want to UseAsPointing
only.
I made a diff for the evdev.c file.
Thanks,
Seba
-int is_ptr = as_mouse || as_touchpad || as_touchscreen || has_scroll;
+int is_ptr = as_mouse || as_touchpad || as_touchscreen;
--- a/evdev.c 2008-12-03 08:36:59.0 +0200
+++ b/evdev.c 2008-12-03 16:20:53.0 +0200
@@ -1333,8 +1333,10 @@
long rel_bitmask[NBITS(REL_MAX)] = {0};
long abs_bitmask[NBITS(ABS_MAX)] = {0};
int i, has_axes, has_keys, num_buttons, has_scroll;
+int as_mouse, as_touchpad, as_touchscreen, as_keyboard;
int kernel24 = 0;
EvdevPtr pEvdev = pInfo->private;
+pointer pOpts = pInfo->options;
if (pEvdev->grabDevice && ioctl(pInfo->fd, EVIOCGRAB, (void *)1)) {
if (errno == EINVAL) {
@@ -1367,6 +1369,8 @@
return 1;
}
+as_mouse = as_touchpad = as_touchscreen = as_keyboard = FALSE;
+
has_axes = FALSE;
has_keys = FALSE;
has_scroll = FALSE;
@@ -1379,91 +1383,139 @@
num_buttons++;
}
-if (num_buttons)
-{
-pEvdev->flags |= EVDEV_BUTTON_EVENTS;
-pEvdev->buttons = num_buttons;
-xf86Msg(X_INFO, "%s: Found %d mouse buttons\n", pInfo->name,
-num_buttons);
-}
-
-if (TestBit(REL_X, rel_bitmask) && TestBit(REL_Y, rel_bitmask)) {
-xf86Msg(X_INFO, "%s: Found x and y relative axes\n", pInfo->name);
- pEvdev->flags |= EVDEV_RELATIVE_EVENTS;
- has_axes = TRUE;
-}
+/* query axes */
+if (TestBit(REL_X, rel_bitmask) && TestBit(REL_Y, rel_bitmask) ||
+TestBit(ABS_X, abs_bitmask) && TestBit(ABS_Y, abs_bitmask))
+has_axes = TRUE;
-if (TestBit(REL_WHEEL, rel_bitmask) || TestBit(REL_HWHEEL, rel_bitmask)) {
-xf86Msg(X_INFO, "%s: Found scroll wheel(s)\n", pInfo->name);
+/* poll scroll */
+if (TestBit(REL_WHEEL, rel_bitmask) || TestBit(REL_HWHEEL, rel_bitmask))
has_scroll = TRUE;
-}
-
-if (TestBit(ABS_X, abs_bitmask) && TestBit(ABS_Y, abs_bitmask)) {
-xf86Msg(X_INFO, "%s: Found x and y absolute axes\n", pInfo->name);
- pEvdev->flags |= EVDEV_ABSOLUTE_EVENTS;
- if (TestBit(BTN_TOUCH, key_bitmask)) {
-if (num_buttons) {
-xf86Msg(X_INFO, "%s: Found absolute touchpad\n", pInfo->name);
-pEvdev->flags |= EVDEV_TOUCHPAD;
-pEvdev->old_x = pEvdev->old_y = -1;
-} else {
-xf86Msg(X_INFO, "%s: Found absolute touchscreen\n",
pInfo->name);
-pEvdev->flags |= EVDEV_TOUCHSCREEN;
-pEvdev->flags |= EVDEV_BUTTON_EVENTS;
-}
- }
- has_axes = TRUE;
-}
+/* find keys */
for (i = 0; i < BTN_MISC; i++)
if (TestBit(i, key_bitmask))
break;
+if (i < BTN_MISC)
+has_keys = TRUE;
-if (i < BTN_MISC) {
-xf86Msg(X_INFO, "%s: Found keys\n", pInfo->name);
- pEvdev->flags |= EVDEV_KEYBOARD_EVENTS;
- has_keys = TRUE;
-}
+/* mouse caps */
if (has_axes && num_buttons) {
-xf86Msg(X_INFO, "%s: Configuring as mouse\n", pInfo->name);
- pInfo->flags |= XI86_POINTER_CAPABLE | XI86_SEND_DRAG_EVENTS |
- XI86_CONFIGURED;
- pInfo->type_name = XI_MOUSE;
+pInfo->flags |= XI86_CONFIGURED;
+as_mouse = TRUE;
}
-if (pEvdev->flags & EVDEV_TOUCHSCREEN) {
-xf86Msg(X_INFO, "%s: Configuring as touchscreen\n", pInfo->name);
-pInfo->type_name = XI_TOUCHSCREEN;
-pInfo->flags |= XI86_POINTER_CAPABLE | XI86_SEND_DRAG_EVENTS |
-XI86_CONFIGURED;
-}
+/* touchscreen/touchpad caps */
+if (TestBit(ABS_X, abs_bitmask) && TestBit(ABS_Y, abs_bitmask))
+if (TestBit(BTN_TOUCH, key_bitmask)) {
+pInfo->flags |= XI86_CONFIGURED;
+xf86Msg(X_INFO, "%s: Found
Re: evdev: keyboard or mouse?
Hi,
xinput --reattach did the trick.
I didn't see the messages "configure as mouse/keyboard/..." as *additive*, so I
thought only one must occur.
But can one "filter" the device so that it is exactly and only a pointer? Or
the reverse?
Ι rewrote a little EvdevProbe's find/configure chain. (including the last
has_scroll commit)
First it goes "dry-run" to detect what can be configured.
If option UseAsPointing is true (can only be from user), it tries to
disregard, in the following, the keys, unless UseAsKeyboard is true as
well.
The same holds for option UseAsKeyboard.
If they are not specified, then there is a normal behavior, covering
any capability and naming as keyboard (so KEYBOARD is sort of like KEYPANEL).
Then it configures what was totally discovered, excluding the what
specifically was *not* requested. It's a simple
auto-include&user-exclude mechanism.
The code is also somehow clearer of what it does, separating the stages: you
can easily track the *additive* style in the end.
It is of course redundant. But it answers the intuitive shallow
question regarding these situations. For me, I want to UseAsPointing
only.
I made a diff for the evdev.c file.
Thanks,
Seba
- Original Message ----
From: Peter Hutterer <[EMAIL PROTECTED]>
To: Sebastian Glita <[EMAIL PROTECTED]>
Cc: xorg@lists.freedesktop.org
Sent: Monday, December 1, 2008 1:41:10 AM
Subject: Re: evdev: keyboard or mouse?
On Fri, Nov 28, 2008 at 05:58:22AM -0800, Sebastian Glita wrote:
> The mice and keyboards in xf86-input-evdev/src/evdev.c:EvdevProbe handle a
> "multiple-capability" device wrong for my use.
>
> I have a wireless USB receiver so I use both a mouse and a keyboard with the
> same token.
>
> In `hal-device`, the device for the mouse also has "input.keys" matching
> "info.capabilities".
>
> I tried in /etc/hal/fdi/10-x11-input.fdi to from
> "info.capabilities" the "info.keys" from this strlist. It works.
The device probing is independent of HAL, so removing this key won't affect
evdev at all.
> The problem is that in `gnome-device-setup' when I drag the name from the
> Virtual Core Pointer it goes only to a keyboard item, and not to the
> "pointer" one (its "use" matches IsXExtensionKeyboard instead of
> IsXExtensionPointer).
Unless someone has actually taken the code and advanced it, I wouldn't trust
on gnome-device-setup 100%. Try xinput --reattach "Virtual core
pointer" and see if that works.
> This small permutation in evdev.c works for me (it disables `has_keys' in
> favor of XI_MOUSE to XI_KEYBOARD):
please always submit code changes as diffs, otherwise it's too hard to figure
out what the actual change was.
> if (has_axes && num_buttons)
> has_keys = FALSE;
No. Doing so means you essentially disable all keys on the device. I've seen
keyboards that advertise buttons and axes (scrollwheel) so you'd be disabling
all these keyboards.
Cheers,
Peter
--- a/evdev.c 2008-12-03 08:36:59.0 +0200
+++ b/evdev.c 2008-12-03 16:20:53.0 +0200
@@ -1333,8 +1333,10 @@
long rel_bitmask[NBITS(REL_MAX)] = {0};
long abs_bitmask[NBITS(ABS_MAX)] = {0};
int i, has_axes, has_keys, num_buttons, has_scroll;
+int as_mouse, as_touchpad, as_touchscreen, as_keyboard;
int kernel24 = 0;
EvdevPtr pEvdev = pInfo->private;
+pointer pOpts = pInfo->options;
if (pEvdev->grabDevice && ioctl(pInfo->fd, EVIOCGRAB, (void *)1)) {
if (errno == EINVAL) {
@@ -1367,6 +1369,8 @@
return 1;
}
+as_mouse = as_touchpad = as_touchscreen = as_keyboard = FALSE;
+
has_axes = FALSE;
has_keys = FALSE;
has_scroll = FALSE;
@@ -1379,91 +1383,139 @@
num_buttons++;
}
-if (num_buttons)
-{
-pEvdev->flags |= EVDEV_BUTTON_EVENTS;
-pEvdev->buttons = num_buttons;
-xf86Msg(X_INFO, "%s: Found %d mouse buttons\n", pInfo->name,
-num_buttons);
-}
-
-if (TestBit(REL_X, rel_bitmask) && TestBit(REL_Y, rel_bitmask)) {
-xf86Msg(X_INFO, "%s: Found x and y relative axes\n", pInfo->name);
- pEvdev->flags |= EVDEV_RELATIVE_EVENTS;
- has_axes = TRUE;
-}
+/* query axes */
+if (TestBit(REL_X, rel_bitmask) && TestBit(REL_Y, rel_bitmask) ||
+TestBit(ABS_X, abs_bitmask) && TestBit(ABS_Y, abs_bitmask))
+has_axes = TRUE;
-if (TestBit(REL_WHEEL, rel_bitmask) || TestBit(REL_HWHEEL, rel_bitmask)) {
-xf86Msg(X_INFO, "%s: Found scroll wheel(s)\n", pInfo->name);
+/* poll scroll */
+if (TestBit(REL_WHEEL, rel_bitmask) || TestBit(REL_HWHEEL, rel_bitmask))
has_scroll = TRUE;
-}
-
-if (Tes
evdev: keyboard or mouse?
Hi,
The mice and keyboards in xf86-input-evdev/src/evdev.c:EvdevProbe handle a
"multiple-capability" device wrong for my use.
I have a wireless USB receiver so I use both a mouse and a keyboard with the
same token.
In `hal-device`, the device for the mouse also has "input.keys" matching
"info.capabilities".
I tried in /etc/hal/fdi/10-x11-input.fdi to from "info.capabilities"
the "info.keys" from this strlist. It works.
The problem is that in `gnome-device-setup' when I drag the name from the
Virtual Core Pointer it goes only to a keyboard item, and not to the "pointer"
one (its "use" matches IsXExtensionKeyboard instead of IsXExtensionPointer).
The "evdev" device is added/configured via ioctl's and the configuration from
hal seems not to be used (it would say weather it originated from matching
either "input.mouse" xor "input.keys").
This small permutation in evdev.c works for me (it disables `has_keys' in favor
of XI_MOUSE to XI_KEYBOARD):
xf86-input-evdev/src/evdev.c:1341
has_axes = FALSE;
has_keys = FALSE;
num_buttons = 0;
/* count all buttons */
for (i = BTN_MISC; i < BTN_JOYSTICK; i++)
{
if (TestBit(i, key_bitmask))
num_buttons++;
}
if (TestBit(REL_X, rel_bitmask) && TestBit(REL_Y, rel_bitmask) ||
TestBit(ABS_X, abs_bitmask) && TestBit(ABS_Y, abs_bitmask))
has_axes = TRUE;
for (i = 0; i < BTN_MISC; i++)
if (TestBit(i, key_bitmask))
break;
if (i < BTN_MISC)
has_keys = TRUE;
if (has_axes && num_buttons)
has_keys = FALSE;
and the rest is almost identical as from #1352, but no `has_keys' assignment.
Thanks -- S.
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: acroread & pdfedit fail on tmp/.X11-unix/X0 socket
solution: recompile pdfedit; use acroread --sync *.pdf --but not for the nppdf.so firefox plugin (libXext/src/extutil.c:126 -- !strcmp instead?) ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
acroread & pdfedit fail on tmp/.X11-unix/X0 socket + libXext/src/extutil.c:126 XGE not registering
Hi,
Running `strace pdfedit *.pdf' this happens after filedescriptor 3 binds the X
unix socket:
gettimeofday({1226575688, 33}, NULL) = 0
socket(PF_FILE, SOCK_STREAM, 0) = 3
connect(3, {sa_family=AF_FILE, path=@"/tmp/.X11-unix/X0"...}, 20) = 0
getpeername(3, {sa_family=AF_FILE, path=@"/tmp/.X11-unix/X0\312\32\20\267"...},
[20]) = 0
uname({sys="Linux", node="localhost", ...}) = 0
access("/home/user/.Xauthority", R_OK) = 0
open("/home/user/.Xauthority", O_RDONLY) = 4
fstat64(4, {st_mode=S_IFREG|0600, st_size=329, ...}) = 0
mmap2(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0xb7ef3000
read(4, "\0\0\0\4\n\300\250\1\0\0010\0\22MIT-MAGIC-COOKIE-1\0\20"..., 4096) =
329
close(4)= 0
munmap(0xb7ef3000, 4096)= 0
time(NULL) = 1226575688
fcntl64(3, F_GETFL) = 0x2 (flags O_RDWR)
fcntl64(3, F_SETFL, O_RDWR|O_NONBLOCK) = 0
fcntl64(3, F_SETFD, FD_CLOEXEC) = 0
select(4, [3], [3], NULL, NULL) = 1 (out [3])
writev(3, [{"l\0\v\0\0\0\23\0\30\0"..., 10}, {"\0\0"..., 2},
{"XDM-AUTHORIZATION-1"..., 19}, {"\0"..., 1},
{"=\316\353\361\0075\310\363\352\254\31}\316\235b\3
60\227\fe(\260\f\7r"..., 24}, {""..., 0}], 6) = 56
read(3, "\1\0\v\0\0\0E\0"..., 8)= 8
read(3, "XC\240\0\0\0 \2\377\377\37\0\0\1\0\0\24\0\377\377\1\7\0\0
\10\377\330\227\"\10T"..., 276) = 276
select(4, [3], [3], NULL, NULL) = 1 (out [3])
writev(3, [{"b\0\5\0\f\0\0\0BIG-REQUESTS"..., 20}], 1) = 20
select(4, [3], [], NULL, NULL) = 1 (in [3])
read(3,
"\1\302\1\0\0\0\0\0\1\202\0\0\1\0\0\0\0\0\0\0\310g\206\10\0\0\0\0\364\17\34\10"...,
16384) = 32
select(4, [3], [3], NULL, NULL) = 1 (out [3])
writev(3, [{"\202\0\1\0"..., 4}], 1)= 4
select(4, [3], [], NULL, NULL) = 1 (in [3])
read(3,
"\1g\2\0\0\0\0\0\377\377?\0\0\0\0\0\310g\206\10\0\0\0\0\364\17\34\10\2045\0\0"...,
16384) = 32
read(3, 0x84bc928, 16384) = -1 EAGAIN (Resource temporarily
unavailable)
select(4, [3], [3], NULL, NULL) = 1 (out [3])
writev(3, [{"7\0\5\0\0\0
\2v\0\0\0\10\0\0\0\377\377\377\0\24\0\6\0v\0\0\0\27\0\0\0\37"..., 44}, {NULL,
0}, {""..., 0}], 3) = 44
and so on, many, many EAGAIN; lastly:
read(4,
"Xcur\20\0\0\0\0\0\1\0\1\0\0\0\2\0\375\377\30\0\0\0\34\0\0\0$\0\0\0\2"...,
4096) = 2368
_llseek(4, 0, [0], SEEK_SET)= 0
read(4,
"Xcur\20\0\0\0\0\0\1\0\1\0\0\0\2\0\375\377\30\0\0\0\34\0\0\0$\0\0\0\2"...,
4096) = 2368
close(4)= 0
munmap(0xb7023000, 4096)= 0
select(4, [3], [3], NULL, NULL) = 1 (out [3])
writev(3,
[{"\224\27\5\0\6\0\240\0\10\0\0\0left_ptr\224\27\5\0\6\0\240\0\10\0\5\0l"...,
5788}, {NULL, 0}, {""..., 0}], 3) = 5788
read(3, 0x84bc928, 16384) = -1 EAGAIN (Resource temporarily
unavailable)
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
+++ killed by SIGSEGV +++
Tracing `strace acroread *.pdf' now would make me not send this email as X
freezes, although the first page is displayed, but not interactive.
Opening the PDF in a browser with acroread plugin shows empty content.
I installed xorg-server 1.5.3, xf86-video-ati from git, everything else from
git, except the new input dependency, because I have a yet unsupported input
device.
I also got hangs one time ago, when in Xorg.0.log I found something like '[mi]
... entered an infinite loop ...'.
Thanks -- S.
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: ati radeon : hangs between CTRL+ALT+Fx's
Hi, I removed all. Still hangs. I disabled Accel. No hangs. I enabled Accel and XAA. Hangs. I disabled RenderAccel and use EXA. No hangs... until now, again :( What I am sure of is that xf86-video-ati 6.9.0 scrambles VGA output, so that forced me to use the version from git; with this, agpgart+radeon+drm kernel modules are loaded, which did not with 6.9.0, and I am sure that because of them the Xorg server hangs, except when enabling "NoAccel", when they are not loaded. The modules are loaded by libdrm package from git, I guess? As in: http://lists.freedesktop.org/archives/xorg/2008-October/039623.html ? Also, there is a noise, probably the fan of the graphics display, which I did not here before 6.9.0 on the laptop !!! Booting another OS the noise resumes. i hope this does not become a support forum for "the other OS's windows' server" :) too... Thanks -- S. - Original Message From: Alex Deucher <[EMAIL PROTECTED]> To: Sebastian Glita <[EMAIL PROTECTED]> Cc: xorg@lists.freedesktop.org Sent: Friday, October 24, 2008 5:24:20 PM Subject: Re: ati radeon : hangs between CTRL+ALT+Fx's On Fri, Oct 24, 2008 at 8:45 AM, Sebastian Glita <[EMAIL PROTECTED]> wrote: > Hi, > > I have an ugly problem with X hangs. > > Just a while ago, before xorg-server 1.5.2, xf86-video-ati used to work > perfect, even with hibernation. > Now xf86-video-ati from git hangs by blanking 2 thirds of the screen, when > switching CTRL+ALT+Fx or resuming from hibernation. > > DRI option enabled or not, it makes no difference; or with or without drm and > radeon modules builtin. (those from git "x11-drm" do not work with 2.6.26 > kernel.) > > Finding similar posts, I tried using "NoAccel" "on": seems to work, yes, but > too slow. > Option "AccelMethod" set to "EXA" has a similar behaviour. Try removing all of the options in your config and see if that helps. Also, this option: Option "AGPFastWrite" "1" Will almost always cause problems. Remove that. Alex ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: RenderAccel not working with git xf86-video-ati Xpress 200M
Hi, Last time it stopped while dragging a window in DualDisplay (:1.0), after some chvt's. Thanks -- S. - Original Message From: Alex Deucher <[EMAIL PROTECTED]> To: Sebastian Glita <[EMAIL PROTECTED]> Cc: xorg@lists.freedesktop.org Sent: Wednesday, October 29, 2008 7:48:33 PM Subject: Re: RenderAccel not working with git xf86-video-ati Xpress 200M On Wed, Oct 29, 2008 at 12:52 PM, Sebastian Glita <[EMAIL PROTECTED]> wrote: > Hi, > > Testing hangs with EXA-patched xorg-server 1.5.2-r1 show either "NoAccel" or > no "RenderAccel" handles it right: Can you post your xorg log with renderaccel enabled? Alex Xorg.0.log.gz Description: application/gzip Xorg.1.log.gz Description: application/gzip ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
RenderAccel not working with git xf86-video-ati Xpress 200M
Hi, Testing hangs with EXA-patched xorg-server 1.5.2-r1 show either "NoAccel" or no "RenderAccel" handles it right: Section "Device" # Identifier "ATI Radeon Xpress 200M [RC410]" # Driver "radeon" # # Chipset "ATI Radeon XPRESS 200M 5A62 (PCIE)" # ChipID 0x5A62 # BusID "PCI:1:5:0" # # Option "PanelSize" "1280x800" # Option "Monitor-LVDS" "LCD 15.4'' WXGA"# Option "Monitor-VGA-0" "" # # Option "RenderAccel" "off"# Option "NoAccel" "false" # Option "AccelMethod" "EXA"# EndSection # Thanks -- S. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
ati radeon : hangs between CTRL+ALT+Fx's
Hi, I have an ugly problem with X hangs. Just a while ago, before xorg-server 1.5.2, xf86-video-ati used to work perfect, even with hibernation. Now xf86-video-ati from git hangs by blanking 2 thirds of the screen, when switching CTRL+ALT+Fx or resuming from hibernation. DRI option enabled or not, it makes no difference; or with or without drm and radeon modules builtin. (those from git "x11-drm" do not work with 2.6.26 kernel.) Finding similar posts, I tried using "NoAccel" "on": seems to work, yes, but too slow. Option "AccelMethod" set to "EXA" has a similar behaviour. These group of options together seem to mask the bug, especially "XAANoPixmapCache", just that alone takes longer to freeze again. Option "XAANoImageWriteRect"# Option "XAANoOffscreenPixmaps" # Option "XAANoPixmapCache" # Option "XAANoScreenToScreenCopy"# Option "XAANoSolidFillRect" # Option "XAANoSolidFillTrap" # The device section is: Section "Device" # Identifier "ATI Radeon Xpress 200M [RC410]" # Driver "radeon" # # Chipset "ATI Radeon XPRESS 200M 5A62 (PCIE)" # ChipID 0x5A62 # BusID "PCI:1:5:0" # # Option "Monitor-LVDS" "LCD 15.4'' WXGA"# Option "Monitor-VGA-0" "" # # #: sw_cursor is needed for some ati and radeon cards :# ## Option "SW_cursor" "true" # Option "DynamicClocks" "on" # # #: (II) Render acceleration unsupported on Radeon 9500/9700 and newer. :# Option "RenderAccel" "off"# #0 Option "NoAccel" "on" # #0 Option "AccelMethod" "EXA"# Option "AccelMethod" "XAA"# # Option "XAANoImageWriteRect"# Option "XAANoOffscreenPixmaps" # Option "XAANoPixmapCache" # Option "XAANoScreenToScreenCopy"# Option "XAANoSolidFillRect" # Option "XAANoSolidFillTrap" # # Option "NoDDC" "true" # Option "DDCMode" "off"# Option "IgnoreEDID""on" # #! Option "BusType" "PCI"# Option "VGAAccess" "off"# Option "Int10" "off"# # #x Option "UseInternalAGPGART""yes"# Option "GARTSize" "64" # Option "AGPMode" "4" # Option "AGPFastWrite" "1" # Option "DMAForXv" "1" # # Option "EnablePageFlip""1" # Option "ColorTiling" "1" # Option "SubPixelOrder" "RGB"# # #! Option "DRI" "off"# Option "DRI" "off"# # #! Option "ModeDebug" "false" # Option "Backingstore" "on" # EndSection # Is this a server or a driver or a conf. bug? Thanks -- S.
