Re: compiz and xorg-server 1.5.99.903
Hi, 'Twas brillig, and Keith Packard at 23/02/09 03:38 did gyre and gimble: On Sun, 2009-02-22 at 19:15 -0800, Tony Bones wrote: /usr/bin/compiz (core) - Fatal: Root visual is not a GL visual /usr/bin/compiz (core) - Error: Failed to manage screen: 0 /usr/bin/compiz (core) - Fatal: No manageable screens found on display :0 There's a minor visual fix on the server-1.6-branch; you might give that a try. I tried that one but it didn't help. In the end the fix I found was to revert: http://cgit.freedesktop.org/xorg/xserver/commit/?h=server-1.6-branchid=444127f9f408d2f517fdfab0092bd67b29073373 Before this, compiz would start but give a white screen on the cube face. More intelligent scripts would probably stop it starting in the first place. Hope this helps. Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Ximage's byte_order field
On Thu, 2009-02-19 at 10:54 -0700, McDonald, Michael-p7438c wrote: Am I allowed to change the value of the XImage byte_order field? And if I do, will subsequent XPutImage() calls do the right thing? Does the value of byte_order default to the client's byte order? The default byte order is the server's byte order. You _can_ change the image's byte_order field, and xlib will do the right thing with that (in the sense of transmitting the bits as you pass them in). But the server will only do the right thing with it if it was built with MATCH_CLIENT_ENDIAN defined, which I don't think is ever the case. Swapping client-side is the Done Thing. We could argue whether that's philosophically correct, and it's probably not, but I think it's what you're stuck with, sorry. - ajax 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: [Bug 19947] xkbcomp-1.0.5: Group width mismatch between key and type
Hi Peter,
thanks for excellent explanations. More below.
Peter Hutterer wrote:
(**) Option xkb_rules evdev
(**) AT Translated Set 2 keyboard: xkb_rules: evdev
(**) Option xkb_model evdev
(**) AT Translated Set 2 keyboard: xkb_model: evdev
(**) Option xkb_layout us,cz
(**) AT Translated Set 2 keyboard: xkb_layout: us,cz
(**) Option xkb_variant ,qwerty
(**) AT Translated Set 2 keyboard: xkb_variant: ,qwerty
(**) Option xkb_options
grp:alt_shift_togglegrp_led:scrollcaps:shift_nocancel
(**) AT Translated Set 2 keyboard: xkb_options:
grp:alt_shift_togglegrp_led:scrollcaps:shift_nocancel
this last line is wrong, see below.
xkb_keymap {
xkb_keycodes evdev+aliases(qwerty) {
[...]
xkb_types complete {
[...]
xkb_compatibility complete {
[...]
xkb_symbols pc+us+cz(qwerty):2+inet(evdev) {
[...]
this is what actually is loaded in the server. You see how all your options
are missing? This is because of a wrong setup (fdi file below).
Until one know how it should look like it is not that clear.
Now I see what had to be there:
(II) config/hal: Adding input device AT Translated Set 2 keyboard
(**) AT Translated Set 2 keyboard: always reports core events
(**) AT Translated Set 2 keyboard: Device: /dev/input/event4
(II) AT Translated Set 2 keyboard: Found keys
(II) AT Translated Set 2 keyboard: Configuring as keyboard
(II) XINPUT: Adding extended input device AT Translated Set 2 keyboard (type:
KEYBOARD)
(**) Option xkb_rules evdev
(**) Option xkb_model pc105
(**) Option xkb_layout us,cz
(**) Option xkb_variant ,qwerty
(**) Option xkb_options
grp:alt_shift_toggle,grp_led:scroll,caps:shift_nocancel
key LFSH { [ Shift_L ] };
key RTSH { [ Shift_R ] };
key LALT { [ Alt_L, Meta_L ] };
key RALT {
type[group2]= ONE_LEVEL,
symbols[Group1]= [ Alt_R, Meta_R ],
symbols[Group2]= [ ISO_Level3_Shift ]
};
here's the details why it doesn't work, the Alt/Shift keys dont have the
required ISO_Next_Group, ISO_Prev_Group they should have, hence group
switching doesn't work.
So here is what I have now compared to the former/broken:
# xkbcomp :0 -xkb out.xkb3
# diff -u -w out.xkb out.xkb3
--- out.xkb 2009-02-12 17:54:32.0 +0100
+++ root/out.xkb3 2009-02-23 16:56:36.0 +0100
@@ -291,7 +291,7 @@
alias LatM = AB07;
};
-xkb_types complete {
+xkb_types complete+caps(shift_nocancel) {
virtual_modifiers
NumLock,Alt,LevelThree,LAlt,RAlt,RControl,LControl,ScrollLock,LevelFive,AltGr,Meta,Super,Hyper;
@@ -309,6 +309,7 @@
modifiers= Shift+Lock;
map[Shift]= Level2;
map[Lock]= Level2;
+map[Shift+Lock]= Level2;
level_name[Level1]= Base;
level_name[Level2]= Caps;
};
@@ -489,10 +490,11 @@
modifiers= Shift+Lock+LevelThree;
map[Shift]= Level2;
map[Lock]= Level2;
+map[Shift+Lock]= Level2;
map[LevelThree]= Level3;
map[Shift+LevelThree]= Level4;
map[Lock+LevelThree]= Level4;
-map[Shift+Lock+LevelThree]= Level3;
+map[Shift+Lock+LevelThree]= Level4;
level_name[Level1]= Base;
level_name[Level2]= Shift;
level_name[Level3]= Alt Base;
@@ -502,6 +504,7 @@
modifiers= Shift+Lock+LevelThree;
map[Shift]= Level2;
map[Lock]= Level2;
+map[Shift+Lock]= Level2;
map[LevelThree]= Level3;
map[Shift+LevelThree]= Level4;
map[Lock+LevelThree]= Level3;
@@ -582,7 +585,7 @@
};
};
-xkb_compatibility complete {
+xkb_compatibility complete+ledscroll(group_lock) {
virtual_modifiers
NumLock,Alt,LevelThree,LAlt,RAlt,RControl,LControl,ScrollLock,LevelFive,AltGr,Meta,Super,Hyper;
@@ -1048,8 +1051,7 @@
modifiers= NumLock;
};
indicator Scroll Lock {
-whichModState= locked;
-modifiers= ScrollLock;
+groups= 0xfe;
};
indicator Shift Lock {
!allowExplicit;
@@ -1066,7 +1068,7 @@
};
};
-xkb_symbols pc+us+cz(qwerty):2+inet(evdev) {
+xkb_symbols pc+us+cz(qwerty):2+inet(evdev)+group(alt_shift_toggle) {
name[group1]=USA;
name[group2]=Czechia - qwerty;
@@ -1278,7 +1280,10 @@
symbols[Group1]= [ grave, asciitilde ],
symbols[Group2]= [ semicolon, dead_abovering, grave,
asciitilde ]
};
-key LFSH { [ Shift_L ] };
+key LFSH {
+type= PC_ALT_LEVEL2,
+symbols[Group1]= [ Shift_L, ISO_Prev_Group ]
+};
key BKSL {
type[group2]= FOUR_LEVEL,
symbols[Group1]= [ backslash, bar ],
@@ -1341,12 +1346,15 @@
symbols[Group1]= [ slash,question ],
symbols[Group2]= [ minus, underscore,asterisk,
dead_abovedot ]
};
-key RTSH { [ Shift_R ] };
+key RTSH {
Re: [Bug 19947] xkbcomp-1.0.5: Group width mismatch between key and type
Martin MOKREJŠ wrote: Forgot to add that the [alt]+[shift] switch works with the setup I have now. Only I suspect that [shift]+twice pressing [=] on the US keyboard layout followed by pressing [u] should generate ů instead of ˇu. But, the character is anyway mapped over the [;] character of US layout. Is there a way to get a graphical layout of the expected buttons from my installation and some reference layout (gif/jpg/ps or X11 live app)? I see xvkbd but it does not change its output if I switch between the keyboard layouts: $ xvkbd xvkbd: Mode_switch not available as a modifier xvkbd: although ISO_Level3_Shift is used instead, AltGr may not work correctly xvkbd: Mode_switch not available as a modifier xvkbd: although ISO_Level3_Shift is used instead, AltGr may not work correctly xvkbd: Mode_switch not available as a modifier xvkbd: although ISO_Level3_Shift is used instead, AltGr may not work correctly xvkbd: Mode_switch not available as a modifier xvkbd: although ISO_Level3_Shift is used instead, AltGr may not work correctly $ Thanks Martin ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Ximage's byte_order field
McDonald, Michael-p7438c wrote: Am I allowed to change the value of the XImage byte_order field? And if I do, will subsequent XPutImage() calls do the right thing? Yes, you can change the byte_order field to match the byte order of your image. XPutImage will take care of swapping your bits around to match what the server expects. See: http://cgit.freedesktop.org/xorg/lib/libX11/tree/src/PutImage.c particularly the function SendZImage, if you want the gory details. Peter Harris -- Open Text Connectivity Solutions Group Peter Harrishttp://www.opentext.com/connectivity Research and DevelopmentPhone: +1 905 762 6001 phar...@opentext.comToll Free: 1 877 359 4866 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: XVideo support in xf86-video-nv / G90
On Sun, Feb 22, 2009 at 09:26:11AM -0800, Henry-Nicolas Tourneur wrote: I would like to know if there are any plans to add XVideo support for G90 cards to the nvidia free 2D driver. I'm afraid not. XV on those GPUs requires the 3D engine, and setting that up is too complicated to be within the scope of that driver. -- Aaron ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Building Xorg/xserver from git
ace102 wrote: Does anyone see any potential problems with using this in my main build script for 1.5.99.903+ : CC=gcc-4.3 LDFLAGS=-L/usr/lib -Wl,-rpath,/lib -Wl,-rpath,/usr/lib PATH=/usr/bin:$PATH ./util/modular/build.sh /usr Also , where would I specify the config options (--enable-dri2,etc) to be passed to the /xserver directory? Set the CONFFLAGS environment variable to include flags that are passed to all configure scripts (unknown flags to other modules should be harmless). See the top of the build.sh script for details. -- -Alan Coopersmith- alan.coopersm...@sun.com Sun Microsystems, Inc. - X Window System Engineering ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
No package 'xcb-xlib' found
Where it may be found? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] xf86-input-acecad 1.3.0
Acecad 1.3.0. Now with advanced Build against server 1.6 technology. Cheers, Peter Alan Coopersmith (2): Remove xorgconfig xorgcfg from See Also list in man page Add README with pointers to mailing list, bugzilla git repos Paulo Cesar Pereira de Andrade (4): Compile warning fixes. Dont dlopen libsysfs.so, instead, link with it when available. Correct wrong check for Linux libsysfs. Janitor: Correct make distcheck and minor configure.ac cleanup. Peter Hutterer (2): Check for XINPUT ABI 3. acecad 1.3.0 git tag: xf86-input-acecad-1.3.0 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-acecad-1.3.0.tar.bz2 MD5: dd8821ea9239d86d67a84912f4702adf xf86-input-acecad-1.3.0.tar.bz2 SHA1: 4d354701cc43ac71388d389a16e61d8378aed0c5 xf86-input-acecad-1.3.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-acecad-1.3.0.tar.gz MD5: 556707cc7b9ece6f4236dccfd3e3e61a xf86-input-acecad-1.3.0.tar.gz SHA1: c21ee17d4c281965a2aa08b0a980caa6a645d747 xf86-input-acecad-1.3.0.tar.gz ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] xf86-input-aiptek 1.2.0
Aiptek 1.2.0. Alan Coopersmith (2): Remove xorgconfig xorgcfg from See Also list in man page Add README with pointers to mailing list, bugzilla git repos Julien Cristau (1): Link against -lm for sqrt() Paulo Cesar Pereira de Andrade (1): Janitor: rework make distcheck Peter Hutterer (3): Check for XINPUT ABI 3. Fix build, xf86Version.h has been superseeded by xorgVersion.h aiptek 1.2.0 git tag: xf86-input-aiptek-1.2.0 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-aiptek-1.2.0.tar.bz2 MD5: ae6702ead7b4040d0761809ee471c934 xf86-input-aiptek-1.2.0.tar.bz2 SHA1: 3eae977b16a34d03d0049730d8d320a1d1717c65 xf86-input-aiptek-1.2.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-aiptek-1.2.0.tar.gz MD5: 3f3ec25983769ff981ace3fb2c451424 xf86-input-aiptek-1.2.0.tar.gz SHA1: fcd693677380e335d0836ec8309ec660ba30b95f xf86-input-aiptek-1.2.0.tar.gz Cheers, Peter pgpQ0u6TTHCtm.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Xrender related question
Hello, all. Having executed a piece of code listed below, I get a green window (as a result of calling XCreateSimpleWindow()) and a black rectangle on top of it (XRenderFillRectangle()). I still get just black, whatever color I set in the 'col' structure. XRenderFindVisualFormat() points to the data field shown on the screenshot attached to this letter. Why doesn't the color of the rectangle depend on the 'col' parameters? Thank you. XRenderColor col; //create simple window (near green background color) at x,y = (20,30) and width,height = (300,200) abc = XCreateSimpleWindow(display, DefaultRootWindow(display), 20,30, 300,200,0,0,3); XMapWindow(display, abc); //create default picture pict = XRenderCreatePicture(display, abc, XRenderFindVisualFormat(display, visual), 0, NULL); //some color col.red = 0; col.green = 127; col.blue = 250; col.alpha = 250; //fill rectangle at x,y=(20,30) and width,height=(40,50) with selected color XRenderFillRectangle(display, PictOpSrc, pict, col, 20,30,40,50); -- Regards, Alexei Babich, circuit engineer, OOO NPP Rezonans, Chelyabinsk, Russia http://www.rez.ru Jabber ID: imp...@jabber.ru attachment: test1_.png___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xrender related question
Alexei Babich wrote: Hello, all. Having executed a piece of code listed below, I get a green window (as a result of calling XCreateSimpleWindow()) and a black rectangle on top of it (XRenderFillRectangle()). I still get just black, whatever color I set in the 'col' structure. XRenderFindVisualFormat() points to the data field shown on the screenshot attached to this letter. Why doesn't the color of the rectangle depend on the 'col' parameters? //some color col.red = 0; col.green = 127; col.blue = 250; col.alpha = 250; XRender uses 16-bit colors. If you multiply these numbers by 257 you should be fine. I would use 0x for the alpha value, though, if the intention is to make the rectangle fully opaque. Also, unless there is a specific reason to use XRender directly, I would recommend using the higher-level cairo library instead. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
xterm: xcb_io.c:454: _XRead: Assertion `dpy-xcb-reply_data != 0' failed.
Hi, The long saga of trying to get a working git xorg continues. I can start the git X with a simple .xinitrc that contains an xterm. However as soon as I press a key xterm dumps core after printing the assert. I thought it might be there was a mismatch between xterm and the newly built libraries so I also ran the test after clearing PATH and LD_LIBRARY_PATH in the .xinitrc. The same assertion fires (although obviously a slightly different line). Any ideas what could be triggering this? -- Alex, homepage: http://www.bennee.com/~alex/ CV: http://www.bennee.com/~alex/cv.php ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xrender related question
XRender uses 16-bit colors. Oh, I read the documentation inattentively. Silly mistake. Thank you. Also, unless there is a specific reason to use XRender directly, I would recommend using the higher-level cairo library instead. Thank you. I believe the use of XRender more appropriate for my purposes than the use cairo. -- Regards, Alexei Babich, circuit engineer, OOO NPP Rezonans, Chelyabinsk, Russia http://www.rez.ru Jabber ID: imp...@jabber.ru ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: No package 'xcb-xlib' found
Le 24/02/2009 03:01, Pedro Izecksohn a écrit : Where it may be found? You need to rebuild xcb. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
