Re: how exactly does X11 work with virtual terminals?
Awesome. That is exactly what I needed. Thanks! On Mon, Dec 19, 2011 at 6:01 PM, Alan Coopersmith alan.coopersm...@oracle.com wrote: On 12/19/11 14:20, James Strother wrote: Quite honestly, I have only a basic understanding for what the virtual terminals are and how they work, so I am baffled as to how I would resolve this issue. Does Xorg really need a virtual terminal, or can I start it without one? Is there another way to sort this out? Sounds like you need the flag that was originally added for the multiseat support in Xorg: -sharevts Share virtual terminals with another X server, if supported by the OS. Google finds pages such as https://help.ubuntu.com/community/MultiseatX that should have more information. -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ 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: Looking for **PAID** help with calling XSendEvent correctly
On Thu, Dec 22, 2011 at 9:20 AM, Aryeh Friedman
aryeh.fried...@gmail.com wrote:
I have a Java program that calls the following code but somehow the
events are not rebroadcasted... from my very limited knowledge of X (I
have known C for years but never used it for GUI work) I highly
suspect I some how got the second arg wrong (it seems that the JAWT
window ID is not the same as the Xorg one)... since this is a high
priority project my client is willing to pay for 1 to 2 hours of
consulting on how to adjust the code to make it work... the final goal
is we want to block all keystrokes not meant for the actual app
(alt-f1:f9, ctl-alt-del, etc.)... namely the client is making a
application to apply standardized tests to distance learning students
and we need to enable a kiosk like mode (the user can not break out
the app [or as much as is possible]... the reason is we want to
prevent the test taker of using this as a work around the closed
book restriction on a closed book test)... I can either have no
event filtering (all events go their intended targets) or filtering
and no forwarding (namely if a invert the test of which process to
terminate on fork(2)).
Note: I tried both InputFocus and PointerFocus for the target win of
the event but that doesn't work nor does key-win. Also I can handle
all the coding except the actual XLib/XCB calls.
// src/c/KioskJNI.c
/**
* Any C needed to make Kiosk Mode work as expected
*
* Copyright (C) 2010-2011. Friedman-Nixon-Wong Enterprises, LLC.
*
* @author aryeh
* @version Mon Dec 5 03:47:46 2011
*/
#include signal.h
#include X11/Xlib.h
#include jawt_md.h
#include client_kiosk_core_KioskJNI.h
/**
* Block all OS signals (param's ignored)
*/
JNIEXPORT void JNICALL
Java_client_kiosk_core_KioskJNI_blockSigs(JNIEnv *env, jclass cls,
jobject comp)
{
Display *dpy=XOpenDisplay(0);
int i=0;
for(i=0;i256;i++)
signal(i,SIG_IGN);
JAWT awt;
printf(fart\n);
// Get the AWT
awt.version = JAWT_VERSION_1_4;
jboolean result = JAWT_GetAWT(env, awt);
JAWT_DrawingSurface* ds=awt.GetDrawingSurface(env, comp);
ds-Lock(ds);
JAWT_DrawingSurfaceInfo* dsi=ds-GetDrawingSurfaceInfo(ds);
JAWT_X11DrawingSurfaceInfo* dsi_win =
(JAWT_X11DrawingSurfaceInfo*)dsi-platformInfo;
printf(dsi %p\n,dsi);
printf(ds %p\n,ds);
jlong win=dsi_win-visualID;
I don't know AWT very well, but I would assume that if it were using
similar naming terminology to the rest of xlib, then I think that
dsi_win-visualID; is probably not the correct
printf(dsi_win %p\n,win);
Have you tried using the result of this in xwininfo -id ?
// Free the drawing surface info
ds-FreeDrawingSurfaceInfo(dsi);
// Unlock the drawing surface
ds-Unlock(ds);
// Free the drawing surface
awt.FreeDrawingSurface(ds);
XGrabKeyboard(dpy, DefaultRootWindow(dpy), True, GrabModeAsync,
GrabModeAsync, CurrentTime);
int pid=fork();
if(!pid) {
return;
}
printf(%d\n,pid);
XEvent ev;
while(1) {
XNextEvent(dpy,ev);
XKeyEvent *key=(XKeyEvent *) ev;
printf(You typed a %d\n,key-keycode);
XSendEvent(dpy,win, True, (KeyPressMask | KeyReleaseMask),
ev);
Have you ensured that the receiving client has selected for
KeyPressMask and KeyReleaseMask ?
Check with xwininfo -id client_id -all
XFlush(dpy);
}
XCloseDisplay(dpy);
}
___
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: smspil...@gmail.com
--
Sam Spilsbury
___
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: Looking for **PAID** help with calling XSendEvent correctly
Thanks for the clue it was not exactly what you said but it gave me
the right idea (namely instead of rebroadcasting I use normal method
calling to make a callback in Java for the keystroke)
On Fri, Dec 23, 2011 at 4:58 AM, Sam Spilsbury smspil...@gmail.com wrote:
On Thu, Dec 22, 2011 at 9:20 AM, Aryeh Friedman
aryeh.fried...@gmail.com wrote:
I have a Java program that calls the following code but somehow the
events are not rebroadcasted... from my very limited knowledge of X (I
have known C for years but never used it for GUI work) I highly
suspect I some how got the second arg wrong (it seems that the JAWT
window ID is not the same as the Xorg one)... since this is a high
priority project my client is willing to pay for 1 to 2 hours of
consulting on how to adjust the code to make it work... the final goal
is we want to block all keystrokes not meant for the actual app
(alt-f1:f9, ctl-alt-del, etc.)... namely the client is making a
application to apply standardized tests to distance learning students
and we need to enable a kiosk like mode (the user can not break out
the app [or as much as is possible]... the reason is we want to
prevent the test taker of using this as a work around the closed
book restriction on a closed book test)... I can either have no
event filtering (all events go their intended targets) or filtering
and no forwarding (namely if a invert the test of which process to
terminate on fork(2)).
Note: I tried both InputFocus and PointerFocus for the target win of
the event but that doesn't work nor does key-win. Also I can handle
all the coding except the actual XLib/XCB calls.
// src/c/KioskJNI.c
/**
* Any C needed to make Kiosk Mode work as expected
*
* Copyright (C) 2010-2011. Friedman-Nixon-Wong Enterprises, LLC.
*
* @author aryeh
* @version Mon Dec 5 03:47:46 2011
*/
#include signal.h
#include X11/Xlib.h
#include jawt_md.h
#include client_kiosk_core_KioskJNI.h
/**
* Block all OS signals (param's ignored)
*/
JNIEXPORT void JNICALL
Java_client_kiosk_core_KioskJNI_blockSigs(JNIEnv *env, jclass cls,
jobject comp)
{
Display *dpy=XOpenDisplay(0);
int i=0;
for(i=0;i256;i++)
signal(i,SIG_IGN);
JAWT awt;
printf(fart\n);
// Get the AWT
awt.version = JAWT_VERSION_1_4;
jboolean result = JAWT_GetAWT(env, awt);
JAWT_DrawingSurface* ds=awt.GetDrawingSurface(env, comp);
ds-Lock(ds);
JAWT_DrawingSurfaceInfo* dsi=ds-GetDrawingSurfaceInfo(ds);
JAWT_X11DrawingSurfaceInfo* dsi_win =
(JAWT_X11DrawingSurfaceInfo*)dsi-platformInfo;
printf(dsi %p\n,dsi);
printf(ds %p\n,ds);
jlong win=dsi_win-visualID;
I don't know AWT very well, but I would assume that if it were using
similar naming terminology to the rest of xlib, then I think that
dsi_win-visualID; is probably not the correct
printf(dsi_win %p\n,win);
Have you tried using the result of this in xwininfo -id ?
// Free the drawing surface info
ds-FreeDrawingSurfaceInfo(dsi);
// Unlock the drawing surface
ds-Unlock(ds);
// Free the drawing surface
awt.FreeDrawingSurface(ds);
XGrabKeyboard(dpy, DefaultRootWindow(dpy), True, GrabModeAsync,
GrabModeAsync, CurrentTime);
int pid=fork();
if(!pid) {
return;
}
printf(%d\n,pid);
XEvent ev;
while(1) {
XNextEvent(dpy,ev);
XKeyEvent *key=(XKeyEvent *) ev;
printf(You typed a %d\n,key-keycode);
XSendEvent(dpy,win, True, (KeyPressMask | KeyReleaseMask),
ev);
Have you ensured that the receiving client has selected for
KeyPressMask and KeyReleaseMask ?
Check with xwininfo -id client_id -all
XFlush(dpy);
}
XCloseDisplay(dpy);
}
___
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: smspil...@gmail.com
--
Sam Spilsbury
___
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: Atmel maXTouch Digitizer touch screen
On 22.12.2011 07:41, Chase Douglas wrote: You can fiddle with the input class like you have been to resolve this. Add these lines to your input class: Driver evdev Option Mode Absolute I did this, but then the clicks by tapping don't work at all anymore. I.e. mouse cursor follows my finger, but I cannot activate anything. Or, fix your driver so it works properly. Simply removing the registration of the BTN_TOOL_EVENT should work. It doesn't even use BTN_TOOL_FINGER. I've seen this exact issue on almost every driver of Android origin, like they're all copy pasted. Do you think I should still proceed this way, given above? You may know this already as well, but your driver/device is only operating as a single-touch capable device. maXTouch chips all support at least some multitouch, IIRC. There is an upstream Linux driver for these chips, and it supports multitouch. Yes, I know. For a start, I'd be quite happy to get a single finger and a nice onscreen keyboard working properly. You mean hid-multitouch or some other one? The hid-multitouch didn't work, because the USD IDs are not registered and apparently the udev rules trich failed as well. I'll try adding the IDs and recompile the kernel, if you think that will make it work properly. Ben ___ 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: Atmel maXTouch Digitizer touch screen
On 12/22/2011 04:48 AM, Ben Bucksch wrote: On 22.12.2011 07:41, Chase Douglas wrote: You can fiddle with the input class like you have been to resolve this. Add these lines to your input class: Driver evdev Option Mode Absolute I did this, but then the clicks by tapping don't work at all anymore. I.e. mouse cursor follows my finger, but I cannot activate anything. If I had to guess, BTN_TOOL_FINGER is likely still getting in the way of things in the evdev driver. Or, fix your driver so it works properly. Simply removing the registration of the BTN_TOOL_EVENT should work. It doesn't even use BTN_TOOL_FINGER. I've seen this exact issue on almost every driver of Android origin, like they're all copy pasted. Do you think I should still proceed this way, given above? It looks like you need to fix your kernel driver. You could hack up xserver-xorg-input-evdev to disregard the BTN_TOOL_FINGER event, but I would only do that if you can't fix the kernel driver. You may know this already as well, but your driver/device is only operating as a single-touch capable device. maXTouch chips all support at least some multitouch, IIRC. There is an upstream Linux driver for these chips, and it supports multitouch. Yes, I know. For a start, I'd be quite happy to get a single finger and a nice onscreen keyboard working properly. You mean hid-multitouch or some other one? The hid-multitouch didn't work, because the USD IDs are not registered and apparently the udev rules trich failed as well. I'll try adding the IDs and recompile the kernel, if you think that will make it work properly. No, the maXTouch chips are handled by atmel_mx_ts in drivers/input/touchscreen/atmel_mx_ts.c. -- Chase ___ 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
Looking for **PAID** help with calling XSendEvent correctly
I have a Java program that calls the following code but somehow the
events are not rebroadcasted... from my very limited knowledge of X (I
have known C for years but never used it for GUI work) I highly
suspect I some how got the second arg wrong (it seems that the JAWT
window ID is not the same as the Xorg one)... since this is a high
priority project my client is willing to pay for 1 to 2 hours of
consulting on how to adjust the code to make it work... the final goal
is we want to block all keystrokes not meant for the actual app
(alt-f1:f9, ctl-alt-del, etc.)... namely the client is making a
application to apply standardized tests to distance learning students
and we need to enable a kiosk like mode (the user can not break out
the app [or as much as is possible]... the reason is we want to
prevent the test taker of using this as a work around the closed
book restriction on a closed book test)... I can either have no
event filtering (all events go their intended targets) or filtering
and no forwarding (namely if a invert the test of which process to
terminate on fork(2)).
Note: I tried both InputFocus and PointerFocus for the target win of
the event but that doesn't work nor does key-win. Also I can handle
all the coding except the actual XLib/XCB calls.
// src/c/KioskJNI.c
/**
* Any C needed to make Kiosk Mode work as expected
*
* Copyright (C) 2010-2011. Friedman-Nixon-Wong Enterprises, LLC.
*
* @author aryeh
* @version Mon Dec 5 03:47:46 2011
*/
#include signal.h
#include X11/Xlib.h
#include jawt_md.h
#include client_kiosk_core_KioskJNI.h
/**
* Block all OS signals (param's ignored)
*/
JNIEXPORT void JNICALL
Java_client_kiosk_core_KioskJNI_blockSigs(JNIEnv *env, jclass cls,
jobject comp)
{
Display *dpy=XOpenDisplay(0);
int i=0;
for(i=0;i256;i++)
signal(i,SIG_IGN);
JAWT awt;
printf(fart\n);
// Get the AWT
awt.version = JAWT_VERSION_1_4;
jboolean result = JAWT_GetAWT(env, awt);
JAWT_DrawingSurface* ds=awt.GetDrawingSurface(env, comp);
ds-Lock(ds);
JAWT_DrawingSurfaceInfo* dsi=ds-GetDrawingSurfaceInfo(ds);
JAWT_X11DrawingSurfaceInfo* dsi_win =
(JAWT_X11DrawingSurfaceInfo*)dsi-platformInfo;
printf(dsi %p\n,dsi);
printf(ds %p\n,ds);
jlong win=dsi_win-visualID;
printf(dsi_win %p\n,win);
// Free the drawing surface info
ds-FreeDrawingSurfaceInfo(dsi);
// Unlock the drawing surface
ds-Unlock(ds);
// Free the drawing surface
awt.FreeDrawingSurface(ds);
XGrabKeyboard(dpy, DefaultRootWindow(dpy), True, GrabModeAsync,
GrabModeAsync, CurrentTime);
int pid=fork();
if(!pid) {
return;
}
printf(%d\n,pid);
XEvent ev;
while(1) {
XNextEvent(dpy,ev);
XKeyEvent *key=(XKeyEvent *) ev;
printf(You typed a %d\n,key-keycode);
XSendEvent(dpy,win, True, (KeyPressMask | KeyReleaseMask), ev);
XFlush(dpy);
}
XCloseDisplay(dpy);
}
___
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
Looking for **PAID** help with calling XSendEvent correctly
I have a Java program that calls the following code but somehow the
events are not rebroadcasted... from my very limited knowledge of X (I
have known C for years but never used it for GUI work) I highly
suspect I some how got the second arg wrong (it seems that the JAWT
window ID is not the same as the Xorg one)... since this is a high
priority project my client is willing to pay for 1 to 2 hours of
consulting on how to adjust the code to make it work... the final goal
is we want to block all keystrokes not meant for the actual app
(alt-f1:f9, ctl-alt-del, etc.)... namely the client is making a
application to apply standardized tests to distance learning students
and we need to enable a kiosk like mode (the user can not break out
the app [or as much as is possible]... the reason is we want to
prevent the test taker of using this as a work around the closed
book restriction on a closed book test)... I can either have no
event filtering (all events go their intended targets) or filtering
and no forwarding (namely if a invert the test of which process to
terminate on fork(2)).
Note: I tried both InputFocus and PointerFocus for the target win of
the event but that doesn't work nor does key-win. Also I can handle
all the coding except the actual XLib/XCB calls.
// src/c/KioskJNI.c
/**
* Any C needed to make Kiosk Mode work as expected
*
* Copyright (C) 2010-2011. Friedman-Nixon-Wong Enterprises, LLC.
*
* @author aryeh
* @version Mon Dec 5 03:47:46 2011
*/
#include signal.h
#include X11/Xlib.h
#include jawt_md.h
#include client_kiosk_core_KioskJNI.h
/**
* Block all OS signals (param's ignored)
*/
JNIEXPORT void JNICALL
Java_client_kiosk_core_KioskJNI_blockSigs(JNIEnv *env, jclass cls,
jobject comp)
{
Display *dpy=XOpenDisplay(0);
int i=0;
for(i=0;i256;i++)
signal(i,SIG_IGN);
JAWT awt;
printf(fart\n);
// Get the AWT
awt.version = JAWT_VERSION_1_4;
jboolean result = JAWT_GetAWT(env, awt);
JAWT_DrawingSurface* ds=awt.GetDrawingSurface(env, comp);
ds-Lock(ds);
JAWT_DrawingSurfaceInfo* dsi=ds-GetDrawingSurfaceInfo(ds);
JAWT_X11DrawingSurfaceInfo* dsi_win =
(JAWT_X11DrawingSurfaceInfo*)dsi-platformInfo;
printf(dsi %p\n,dsi);
printf(ds %p\n,ds);
jlong win=dsi_win-visualID;
printf(dsi_win %p\n,win);
// Free the drawing surface info
ds-FreeDrawingSurfaceInfo(dsi);
// Unlock the drawing surface
ds-Unlock(ds);
// Free the drawing surface
awt.FreeDrawingSurface(ds);
XGrabKeyboard(dpy, DefaultRootWindow(dpy), True, GrabModeAsync,
GrabModeAsync, CurrentTime);
int pid=fork();
if(!pid) {
return;
}
printf(%d\n,pid);
XEvent ev;
while(1) {
XNextEvent(dpy,ev);
XKeyEvent *key=(XKeyEvent *) ev;
printf(You typed a %d\n,key-keycode);
XSendEvent(dpy,win, True, (KeyPressMask | KeyReleaseMask), ev);
XFlush(dpy);
}
XCloseDisplay(dpy);
}
___
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
[ANNOUNCE] libXi 1.5.99.2
A rather small set of changes, the XI 2.2 additions are all in just one patch instead of a set of them. Grab this one if you want to start testing multitouch features (once the server is there). Peter Hutterer (3): Bump to 1.5.99.1 Implement support for XI 2.2 libXi 1.5.99.2 git tag: libXi-1.5.99.2 http://xorg.freedesktop.org/archive/individual/lib/libXi-1.5.99.2.tar.bz2 MD5: b0719f6be5eda663a0a1fbac5aa00c76 libXi-1.5.99.2.tar.bz2 SHA1: 7c1be5426297889daac91c0d669200ea3ec93582 libXi-1.5.99.2.tar.bz2 SHA256: 855e91bc7bd61b2870373bf3b081eb76bd320e2104c4ee7b5018473092d76e5c libXi-1.5.99.2.tar.bz2 http://xorg.freedesktop.org/archive/individual/lib/libXi-1.5.99.2.tar.gz MD5: 831824136b92c2a4147b6d02d950aa49 libXi-1.5.99.2.tar.gz SHA1: 1883ffd78db9f5e70322ed6f551e43fbaea275d9 libXi-1.5.99.2.tar.gz SHA256: 90443bd649f38828f5b71d4fd842f5b735d26c110d540f39349a8bcb858c27b2 libXi-1.5.99.2.tar.gz pgp6I2STNYvp0.pgp Description: PGP signature ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] libXi 1.5.99.2
A rather small set of changes, the XI 2.2 additions are all in just one patch instead of a set of them. Grab this one if you want to start testing multitouch features (once the server is there). Peter Hutterer (3): Bump to 1.5.99.1 Implement support for XI 2.2 libXi 1.5.99.2 git tag: libXi-1.5.99.2 http://xorg.freedesktop.org/archive/individual/lib/libXi-1.5.99.2.tar.bz2 MD5: b0719f6be5eda663a0a1fbac5aa00c76 libXi-1.5.99.2.tar.bz2 SHA1: 7c1be5426297889daac91c0d669200ea3ec93582 libXi-1.5.99.2.tar.bz2 SHA256: 855e91bc7bd61b2870373bf3b081eb76bd320e2104c4ee7b5018473092d76e5c libXi-1.5.99.2.tar.bz2 http://xorg.freedesktop.org/archive/individual/lib/libXi-1.5.99.2.tar.gz MD5: 831824136b92c2a4147b6d02d950aa49 libXi-1.5.99.2.tar.gz SHA1: 1883ffd78db9f5e70322ed6f551e43fbaea275d9 libXi-1.5.99.2.tar.gz SHA256: 90443bd649f38828f5b71d4fd842f5b735d26c110d540f39349a8bcb858c27b2 libXi-1.5.99.2.tar.gz pgpoEb7L40L1S.pgp Description: PGP signature ___ 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
[ANNOUNCE] xinput 1.5.4
One fix required for xinput to work when compiled against newer inputproto headers. Without this fix, xinput will check the server for whichever the current protocol version is (or higher) and fail if that version is not present. If you are updating the inputproto headers to 2.1 or a 2.2RC, you will need this update. Peter Hutterer (2): list: don't use defines for checking server version. xinput 1.5.4 git tag: xinput-1.5.4 http://xorg.freedesktop.org/archive/individual/app/xinput-1.5.4.tar.bz2 MD5: 69cd4dea77915b87c106003668378749 xinput-1.5.4.tar.bz2 SHA1: 4e77f4034aa4bc720726beb0795d77a47a71d2c8 xinput-1.5.4.tar.bz2 SHA256: a8da86f0d7c8ac0c4434e3140ae7f208fc2b35869e5adf10971eef7cb77f4360 xinput-1.5.4.tar.bz2 http://xorg.freedesktop.org/archive/individual/app/xinput-1.5.4.tar.gz MD5: f6b165d11d7c46b7113aaa9ecc380d51 xinput-1.5.4.tar.gz SHA1: 82a3f64f8ec2cca2c1f22247367004727a41864f xinput-1.5.4.tar.gz SHA256: ffdee8ae80e1ad62f266f4e537a9809920fbfca670185cd9131d4896d6fd5035 xinput-1.5.4.tar.gz pgpWRpyC9IOlr.pgp Description: PGP signature ___ 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: Atmel maXTouch Digitizer touch screen
On Wed, Dec 21, 2011 at 11:52:39PM +0100, Ben Bucksch wrote: I have unsuccessfully tried the whole day to configure the Atmel maXTouch Digitizer with USB ID 03eb:211c . This is a touch screen and does appear in X.org as input device. It is working rudimentary, but bad enough to be unusable. The machine is a Samsung Series 7 Slate XE700T1A, a tablet with standard notebook hardware. I am using Ubuntu 11.10 with Ubuntu kernel 3.0.0-14-generic and xorg-server 1.10.4-1ubuntu4.2. Problems: 1. ABSOLUTE By default, it's configured in Mode RELATIVE, but it's ABSOLUTE. When I do xinput --set-mode Atmel Atmel maXTouch Digitizer ABSOLUTE it works. But I need it at the login screen already. I do not understand how to just change certain config options about an input device without changing the whole config. When I put in /etc/X11/x.org.conf.d/atmel.conf : Section InputClass Identifier Atmel touchscreen MatchProduct Atmel Atmel maXTouch Digitizer MatchIsTouchpad on Option Mode Absolute EndSection then I get a complaint in the X.org log that the Driver is missing (yes, I shouldn't get that and I don't understand why I do). If I use Driver synaptics, X.org log complains that it's not a synaptics device. If I use Driver evdev, the clicking (mouse button, tapping) doesn't at all work anymore. Either way, this should work OOTB. Can somebody please fix the driver to make it know that this device is ABSOLUTE? please attach your log, it's too hard to guess which configuration doesn't apply correctly. 2. Button not released Sometimes, it generates only button 1 pressed, but not button 1 released. as Chase said, probably broken kernel driver or device. 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: Atmel maXTouch Digitizer touch screen
Hey Chase, thanks for your answer. On 22.12.2011 01:41, Chase Douglas wrote: A capture of the evdev events would be necessary to debug the issue. You can use evtest to do this. Done http://www.bucksch.org/xfer/1.evtest The beginning of the log is my finger moving across the screen, in all 4 corners. The end is me tapping on the screen, double-clicking/-tapping, and clicking/tapping long. xinput --list-props 15 gives http://www.bucksch.org/xfer/1.props Xorg.0.log extract http://www.bucksch.org/xfer/Xorg.0.log It needs to conform to what is stated at: Sorry, but I can't judge that. Ben ___ 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: Atmel maXTouch Digitizer touch screen
On 12/21/2011 09:25 PM, Ben Bucksch wrote: Hey Chase, thanks for your answer. On 22.12.2011 01:41, Chase Douglas wrote: A capture of the evdev events would be necessary to debug the issue. You can use evtest to do this. Done http://www.bucksch.org/xfer/1.evtest Your driver is reporting the availability of BTN_TOOL_FINGER. This is only valid for touchpads. That's why the synaptics driver is loading instead of the evdev driver. You can fiddle with the input class like you have been to resolve this. Add these lines to your input class: Driver evdev Option Mode Absolute Or, fix your driver so it works properly. Simply removing the registration of the BTN_TOOL_EVENT should work. It doesn't even use BTN_TOOL_FINGER. I've seen this exact issue on almost every driver of Android origin, like they're all copy pasted. Hopefully, with either of these two resolutions things will work right. I don't see anything else wrong. You may know this already as well, but your driver/device is only operating as a single-touch capable device. maXTouch chips all support at least some multitouch, IIRC. There is an upstream Linux driver for these chips, and it supports multitouch. I've heard that at least nVidia has switched over to using it, though their previous driver supported multitouch too. -- Chase ___ 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
[ANNOUNCE] libXi 1.5.0
libXi 1.5.0 is an interim version of libXi that includes the smooth scrolling support that XI 2.1 brings. Note that no servers released by X.Org currently supports smooth scrolling, this feature is still limited to the 1.12 development versions. In addition to the smooth scrolling support, this release brings a number of cleanups, bugfixes (most of which were on 1.4.5) and a set of man page improvements. Alan Coopersmith (3): Move Xinput server API documentation from libXi to xserver Fix the FIXME output in man page .TH macros generated by asciidoc Make shadow man pages generated by asciidoc work with Solaris man Gaetan Nadon (13): Documentation: add Docbook external references support make: remove unneeded AM_V_GEN silent rule directive. make: use AM_V_at rather than AM_V_GEN to prefix the mv command Install target dbs alongside generated documents Install xml versions of specs even if HAVE_XMLTO is false docbook.am: global maintenance update - entities, images and olinking docbook.am: embed css styles inside the HTML HEAD element docs: remove productnumber which is not used by default docs: use the fullrelvers; entity to set X11 release information inputlib: fix copyright statements inputlib: prefix 1.0 with the word Version inputlib: restore original title X Input Device Extension Library specs: refactor and complete copyright legal text Jeremy Huddleston (1): Use AM_CPPFLAGS to use in tree headers before installed headers Matt Dew (2): Add id attributes to funcsynopsis to allow other docs to olink to them. 1 - fix the capitalization of the ID attriutes to match either the Matthieu Herrb (1): Fix XISelectEvents on 64 bits, strict alignement architectures. Peter Hutterer (34): Allocate enough memory for raw events + extra data. XIChangeHierarchy: Return Success early if no actual changes are requested. Remove a few unused assignments. man: fix typo, layout in XGetExtensionVersion.man Silence compiler warning in XListDProp.c Silence compiler warning due to differnent event conversion procs man: fix missing comma in XIGrabEnter man page Use Data, not Data32 in XIPassiveGrabDevice man: Fix wrong event names in XIGrabButton. man: Fix typo in XIChangeProperty Bump to 1.4.99 man: Fix formatting in XGetFeedbackControl Add XI2 library-internal array offsets to XIint.h Don't use the protocol defines for 2.0 versioning. Handle unknown device classes. man: fix typo in XIQueryDevice man page man: update property and grab man pages for new constants Handle unknown device classes. man: fix typo in XIQueryDevice man page man: update property and grab man pages for new constants Require inputproto 2.0.99.1 or later Support XI 2.1 internally Support XI 2.1 XIScrollClass Use a separate nclasses variable in XIQueryDevice Remove superfluous assignment of lib-classes in XIQueryDevices. Bump to 1.4.99.1 man: fix #include for XIGrabButton man: XIGrabButton returns error codes, not status codes man: passive grabs return the number of failed modifier combinations Fix duplicate sizeof in copy_classes Stop unnecessary calls to size_classes Include config.h from source files man: minor formatting fix in XIGrabButton libXi 1.5.0 git tag: libXi-1.5.0 http://xorg.freedesktop.org/archive/individual/lib/libXi-1.5.0.tar.bz2 MD5: eed79448dd24b31f3fedb1750fc777b3 libXi-1.5.0.tar.bz2 SHA1: 2d5219ecd270ba985f3a6f4fa3a17c033bb05b78 libXi-1.5.0.tar.bz2 SHA256: fa4a9e4749a439c7a7911e366a898862158c802a0ff8ea0c73f98201aefb4f85 libXi-1.5.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/lib/libXi-1.5.0.tar.gz MD5: 0a67031dfb02284ee8de297c4aad6743 libXi-1.5.0.tar.gz SHA1: c9b7b005685548d5ebe51e0e270a7c9aba5b6d0a libXi-1.5.0.tar.gz SHA256: 083a520bb9a8cbbfa2b502ddf89cf027e47f24dcce35f087ae54070181f05a5a libXi-1.5.0.tar.gz pgprOCoMel6fz.pgp Description: PGP signature ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] inputproto 2.1.99.4
The XI 2.2 (multitouch) protocol spec is now merged into master, so here's a new snapshot after the merge. Most of these commits were part of XI 2.1, the announce generator is a bit naïve. No functional changes in the input protocol since 2.1.99.3. The protocol does not require any configure flags or defines anymore. One bugfix: the dropped libXi version defines are reinstated so this version should work with older versions of libXi. Cyril Brulebois (1): specs: Fix tiny typo. Peter Hutterer (14): specs: clarify that Preferred scroll valuators are per scroll direction specs: We're up to version 2.1 now, say so specs: scroll events have no specific event type, state so. specs: smooth scrolling was added in 2.1, say so specs: typo fix specs: drop leftover from active_touches removal specs: clarify button state in touch events inputproto 2.1 Drop wrong comment for sourceid in TouchOwnershipEvents Reinstate libXi's version defines specs: remove parts of the Work in progress warning Remove --enable-unstable-protocol configure option specs: add XI 2.1 release to history section inputproto 2.1.99.4 git tag: inputproto-2.1.99.4 http://xorg.freedesktop.org/archive/individual/proto/inputproto-2.1.99.4.tar.bz2 MD5: 32f30ddfa1a69b142f3ed12ee501f5e8 inputproto-2.1.99.4.tar.bz2 SHA1: d269d2da4b4812a5dd49d5d678803489b24dd5b8 inputproto-2.1.99.4.tar.bz2 SHA256: 9446966f39596657bd7fe7bab715faf95b118bf9c5962becd67ed0a17572c5f2 inputproto-2.1.99.4.tar.bz2 http://xorg.freedesktop.org/archive/individual/proto/inputproto-2.1.99.4.tar.gz MD5: 8a2c92e64cf94900ba86a91ff63d6fbc inputproto-2.1.99.4.tar.gz SHA1: 669a431a7ed9ba74e72592e225695b527faa9a85 inputproto-2.1.99.4.tar.gz SHA256: 5da1e3a09a6f0c661dfe6ca9a753ca74992bb36466f4bcfa0282e198ca438b98 inputproto-2.1.99.4.tar.gz pgp3ZxvzZpaiG.pgp Description: PGP signature ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] libXi 1.5.0
libXi 1.5.0 is an interim version of libXi that includes the smooth scrolling support that XI 2.1 brings. Note that no servers released by X.Org currently supports smooth scrolling, this feature is still limited to the 1.12 development versions. In addition to the smooth scrolling support, this release brings a number of cleanups, bugfixes (most of which were on 1.4.5) and a set of man page improvements. Alan Coopersmith (3): Move Xinput server API documentation from libXi to xserver Fix the FIXME output in man page .TH macros generated by asciidoc Make shadow man pages generated by asciidoc work with Solaris man Gaetan Nadon (13): Documentation: add Docbook external references support make: remove unneeded AM_V_GEN silent rule directive. make: use AM_V_at rather than AM_V_GEN to prefix the mv command Install target dbs alongside generated documents Install xml versions of specs even if HAVE_XMLTO is false docbook.am: global maintenance update - entities, images and olinking docbook.am: embed css styles inside the HTML HEAD element docs: remove productnumber which is not used by default docs: use the fullrelvers; entity to set X11 release information inputlib: fix copyright statements inputlib: prefix 1.0 with the word Version inputlib: restore original title X Input Device Extension Library specs: refactor and complete copyright legal text Jeremy Huddleston (1): Use AM_CPPFLAGS to use in tree headers before installed headers Matt Dew (2): Add id attributes to funcsynopsis to allow other docs to olink to them. 1 - fix the capitalization of the ID attriutes to match either the Matthieu Herrb (1): Fix XISelectEvents on 64 bits, strict alignement architectures. Peter Hutterer (34): Allocate enough memory for raw events + extra data. XIChangeHierarchy: Return Success early if no actual changes are requested. Remove a few unused assignments. man: fix typo, layout in XGetExtensionVersion.man Silence compiler warning in XListDProp.c Silence compiler warning due to differnent event conversion procs man: fix missing comma in XIGrabEnter man page Use Data, not Data32 in XIPassiveGrabDevice man: Fix wrong event names in XIGrabButton. man: Fix typo in XIChangeProperty Bump to 1.4.99 man: Fix formatting in XGetFeedbackControl Add XI2 library-internal array offsets to XIint.h Don't use the protocol defines for 2.0 versioning. Handle unknown device classes. man: fix typo in XIQueryDevice man page man: update property and grab man pages for new constants Handle unknown device classes. man: fix typo in XIQueryDevice man page man: update property and grab man pages for new constants Require inputproto 2.0.99.1 or later Support XI 2.1 internally Support XI 2.1 XIScrollClass Use a separate nclasses variable in XIQueryDevice Remove superfluous assignment of lib-classes in XIQueryDevices. Bump to 1.4.99.1 man: fix #include for XIGrabButton man: XIGrabButton returns error codes, not status codes man: passive grabs return the number of failed modifier combinations Fix duplicate sizeof in copy_classes Stop unnecessary calls to size_classes Include config.h from source files man: minor formatting fix in XIGrabButton libXi 1.5.0 git tag: libXi-1.5.0 http://xorg.freedesktop.org/archive/individual/lib/libXi-1.5.0.tar.bz2 MD5: eed79448dd24b31f3fedb1750fc777b3 libXi-1.5.0.tar.bz2 SHA1: 2d5219ecd270ba985f3a6f4fa3a17c033bb05b78 libXi-1.5.0.tar.bz2 SHA256: fa4a9e4749a439c7a7911e366a898862158c802a0ff8ea0c73f98201aefb4f85 libXi-1.5.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/lib/libXi-1.5.0.tar.gz MD5: 0a67031dfb02284ee8de297c4aad6743 libXi-1.5.0.tar.gz SHA1: c9b7b005685548d5ebe51e0e270a7c9aba5b6d0a libXi-1.5.0.tar.gz SHA256: 083a520bb9a8cbbfa2b502ddf89cf027e47f24dcce35f087ae54070181f05a5a libXi-1.5.0.tar.gz pgpiJvOG1XOnc.pgp Description: PGP signature ___ 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
[ANNOUNCE] inputproto 2.1.99.4
The XI 2.2 (multitouch) protocol spec is now merged into master, so here's a new snapshot after the merge. Most of these commits were part of XI 2.1, the announce generator is a bit naïve. No functional changes in the input protocol since 2.1.99.3. The protocol does not require any configure flags or defines anymore. One bugfix: the dropped libXi version defines are reinstated so this version should work with older versions of libXi. Cyril Brulebois (1): specs: Fix tiny typo. Peter Hutterer (14): specs: clarify that Preferred scroll valuators are per scroll direction specs: We're up to version 2.1 now, say so specs: scroll events have no specific event type, state so. specs: smooth scrolling was added in 2.1, say so specs: typo fix specs: drop leftover from active_touches removal specs: clarify button state in touch events inputproto 2.1 Drop wrong comment for sourceid in TouchOwnershipEvents Reinstate libXi's version defines specs: remove parts of the Work in progress warning Remove --enable-unstable-protocol configure option specs: add XI 2.1 release to history section inputproto 2.1.99.4 git tag: inputproto-2.1.99.4 http://xorg.freedesktop.org/archive/individual/proto/inputproto-2.1.99.4.tar.bz2 MD5: 32f30ddfa1a69b142f3ed12ee501f5e8 inputproto-2.1.99.4.tar.bz2 SHA1: d269d2da4b4812a5dd49d5d678803489b24dd5b8 inputproto-2.1.99.4.tar.bz2 SHA256: 9446966f39596657bd7fe7bab715faf95b118bf9c5962becd67ed0a17572c5f2 inputproto-2.1.99.4.tar.bz2 http://xorg.freedesktop.org/archive/individual/proto/inputproto-2.1.99.4.tar.gz MD5: 8a2c92e64cf94900ba86a91ff63d6fbc inputproto-2.1.99.4.tar.gz SHA1: 669a431a7ed9ba74e72592e225695b527faa9a85 inputproto-2.1.99.4.tar.gz SHA256: 5da1e3a09a6f0c661dfe6ca9a753ca74992bb36466f4bcfa0282e198ca438b98 inputproto-2.1.99.4.tar.gz pgp6GGS52momP.pgp Description: PGP signature ___ 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
[ANNOUNCE] libXi 1.4.5
libXi 1.4.4 caused requests to fail if the library was built against 2.1 or 2.2 protocol headers. Instead of requiring 2.0 for XI2 requests, the library required the protocol version (2.1 or 2.2 depending on the proto) and failed if the server did not support that version. This again caused virtually all XI2 requests to fail if you didn't happen to run an X server from git. The patch below hardcodes 2.0 for those requests that require 2.0, regardless of the protocol version. You are strongly enocuraged to update. This issue is not visible when built against inputproto 2.0.x Peter Hutterer (2): Don't use the protocol defines for 2.0 versioning. libXi 1.4.5 git tag: libXi-1.4.5 http://xorg.freedesktop.org/archive/individual/lib/libXi-1.4.5.tar.bz2 MD5: 82dcdc76388116800a2c3ad969f510a4 libXi-1.4.5.tar.bz2 SHA1: 8ac24dec8e488f49fd6a6b256c815da9ceec9737 libXi-1.4.5.tar.bz2 SHA256: 22a99123229d22e6e1567c4cda0224a744475f427625d61b23d965157a86f1b5 libXi-1.4.5.tar.bz2 http://xorg.freedesktop.org/archive/individual/lib/libXi-1.4.5.tar.gz MD5: 47a383f7358489df0a57e9b89e3eb220 libXi-1.4.5.tar.gz SHA1: e50f5606b70555f61457f40067e6d8120dcb40ac libXi-1.4.5.tar.gz SHA256: b083c8d6094b9c9d856ebc46cb194d6f7038a729ed352a9c19bfb288ef576b46 libXi-1.4.5.tar.gz pgpPT440VgEdB.pgp Description: PGP signature ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
how exactly does X11 work with virtual terminals?
Hello, I posted to this list a few days ago, and received enough help that I was able to push through to the next problem (thanks again). Briefly, I would like to have two separate monitors connected to the same machine, each running from a separate graphics card and a separate instance of Xorg. The reason for running two instances rather than using xinerama is to prevent actions on the first screen from causing random dropped frames on the second (this for use in a computer vision application, where dropped frames require the entire sequence to be failed and repeated). So far, I have created two xorg.conf files, each specifies the appropriate BusID field, and uses the SingleCard option in the ServerLayout section. All this works fine, and the two instances fire up and run perfectly. The problem is that they are run on two different linux virtual terminals, so they do not display simultaneously. I can switch back and forth between the virtual terminals and each displays on the appropriate monitors, but I can't get them to run simultaneously on both monitors because I can only be in one virtual terminal at a time. Quite honestly, I have only a basic understanding for what the virtual terminals are and how they work, so I am baffled as to how I would resolve this issue. Does Xorg really need a virtual terminal, or can I start it without one? Is there another way to sort this out? Any help would be very much appreciated. Thanks, James ___ 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: how exactly does X11 work with virtual terminals?
On 12/19/11 14:20, James Strother wrote: Quite honestly, I have only a basic understanding for what the virtual terminals are and how they work, so I am baffled as to how I would resolve this issue. Does Xorg really need a virtual terminal, or can I start it without one? Is there another way to sort this out? Sounds like you need the flag that was originally added for the multiseat support in Xorg: -sharevts Share virtual terminals with another X server, if supported by the OS. Google finds pages such as https://help.ubuntu.com/community/MultiseatX that should have more information. -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ 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: xorg Digest, Vol 77, Issue 8
Hi everybody How can I find best resolution for L1752S LG monitor and make changes in xorg.conf. Is there any other solution? My fedora14 does not recognize the monitor. Thanks ___ 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
[ANNOUNCE] xorg-server 1.11.3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 == Description == xorg-server 1.11.3 is the third maintenance release of the 1.11 branch of the X11 server. It contains fixes for various crashes and other correctness issues fixed since the previous release. == Known Issues == Important issues are listed in the 1.11 tracker bug: https://bugs.freedesktop.org/show_bug.cgi?id=xserver-1.11 * #17013: Issues when mising Xinerama and XCopyArea/Xdamage * Partial patch is available... still waiting on complete fix * #29251: [from 1.8.x] server crash destroying GLX pixmaps * #39580: [from 1.9.x] crash in GLX when resizing a window * #39949: [from 1.9.x] RandR panning scaling don't work * #41124: [from 1.9.x] Another crash in GLX/DRI2 when resizing a window Soime additional known issues from the 1.12 tracker would be considered for 1.11 if a fix becomes available: https://bugs.freedesktop.org/show_bug.cgi?id=xserver-1.12 * #11053: Buffer overflow in fbCopyArea() * Has a patch, ajax thinks the patch is wrong * #23938: [from 1.6.x] keys occasionally get stuck * #24094: CTRL-ALT-F1 doesn't switch to VT1 (provides garbage input to terminal instead) * XKB weirdness. This looks diagnosed, so let's get a patch tested. * #27428: xrandr events delayed until a key is pressed * #27804: Enter/Leave event woes with multiple master devices * #31501: [from 1.8.x] crash accessing font info with xfs in fontpath * #32765: [from 1.8.x] Xephyr segfaults on 24bpp hosts * A possible fix is discussed, but Keith didn't like it. * #39094: WaitFor does not handle EIO (causes 100% cpu load) == New Issues == If you encounter an issue that you think should block a future 1.11 release, please follow the instructions listed in the wiki to raise this to our attention. http://www.x.org/wiki/Server111Branch == Changes since 1.11.2 == Adam Jackson (1): fbdevhw: iterate over all modes that match a mode. (v3) Alan Coopersmith (2): Limit the number of screens Xvfb will attempt to allocate memory for LoaderOpen returns either a valid pointer or NULL, so don't check for 0 Chris Wilson (3): VidMode: prevent crash with no modes DRI2: Avoid a NULL pointer dereference dri2: Register the DRI2DrawableType after server regeneration Christopher Yeleighton (1): Bug 38420: Xvfb crashes in miInitVisuals() when started with depth=2 Dave Airlie (7): xf86Crtc: handle no outputs with no modes harder. xext: don't free uninitialised pointer when malloc fails. (v2) Xi: avoid overrun of callback array. xaa: avoid possible freed pointer reuse in epilogue xv: test correct number of requests. (v2) hal: free tmp_val in one missing case kdrive: drop screen crossing code. Derek Buitenhuis (1): Fix vesa's VBE PanelID interpretation Gaetan Nadon (1): dmx: fix distcheck failure, missing compsize.h in Makefile.am Jeremy Huddleston (5): xfree86: Fix powerpc build with -Werror=int-to-pointer-cast -Werror=pointer-to-int-cast dmx: Build fix for -Werror=implicit-function-declaration configure.ac: 1.11.2.901 (1.11.3 RC1) configure.ac: 1.11.2.902 (1.11.3 RC2) configure.ac: 1.11.3 Peter Hutterer (4): dix: block signals when closing all devices Xi: allow passive keygrabs on the XIAll(Master)Devices fake devices dix: Don't let a driver without a ProximityClassRec post events include: export GetProximityEvents and QueueProximityEvents Rami Ylimäki (1): record: Prevent out of bounds access when recording a reply. Ross Burton (1): edid: Add quirk for Acer Aspire One 110 Rui Matos (1): randr: Make the RRConstrainCursorHarder logic the same as miPointerSetPosition dtakahashi42 (1): rootless: Fix a server crash when choosing a color with the gimp color wheel git tag: xorg-server-1.11.3 http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.11.3.tar.bz2 MD5: a7194c437963627e1db0dd2d6c1a1984 xorg-server-1.11.3.tar.bz2 SHA1: 1ca113eb8d371539467518319aab867f20722930 xorg-server-1.11.3.tar.bz2 SHA256: d3852243a42e1d7013ff2b89ce038dfcadcf86ba34ef4f16bcf85e7ebce28918 xorg-server-1.11.3.tar.bz2 http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.11.3.tar.gz MD5: 2b40bba6707c095a71808658ad0900c8 xorg-server-1.11.3.tar.gz SHA1: 93083e1894b30ffdd58ffb0a2772ade6b2d106b3 xorg-server-1.11.3.tar.gz SHA256: 61cd9949985b1c9aa3d0c5542b2808139ac8164fd83aa45eee77368ca85a67d3 xorg-server-1.11.3.tar.gz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) iD8DBQFO6/ksjC1Anjf1NmMRAq2xAJ9BpyfQC3YmIaABv0dXO3zuNDInmgCfeW46 jqLm+444Ey6b/bvMCnjLgkM= =QhXD -END PGP SIGNATURE- ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] xorg-server 1.11.99.2
Here's the second 1.12 snapshot release. Most of this is cleanups from alanc and preparatory work for the Xi 2.2 integration. It looks like that piece is nearly ready to merge; Peter has put the changes out for review. When that's finished, the merge window will be closed. There are a couple of patch sets which are outstanding today: * Gaetan's changes to the server C flags. I'd like to see some discussion about these as I don't quite get the rational. * Jamey's GC clipping changes. These have been reviewed and are pretty much ready for merging. I looked over them and offered a few comments, but I don't see any reason they can't get merged this week. One week to go... Adam Jackson (1): fbdevhw: iterate over all modes that match a mode. (v3) Alan Coopersmith (69): Fix Xdmx build on Linux to work with strlcpy changes Don't fallback to wsfb or fbdev on Solaris Don't require ld -wrap for tests that don't need it Enable memory checking during unit testing Remove a couple Error() instances left behind by 09dbfcb0ad7b6c8 Fix Sun compiler check that got turned around Add fallback implementation of strndup() Convert some malloc + strncpy pairs into strndup calls Convert AllocXTestDevice to use asprintf Convert strncpy/strncat to strlcpy/strlcat matchDriverFromFiles: use one snprintf instead of strncpy/cat series Convert dmxSetDefaultFontPath to use strdup instead of malloc+strncpy Convert DetermineClientCmd to use strdup instead of malloc+strncpy Convert ProcRenderQueryFilters to use memcpy instead of strncpy Make XIGetKnownProperty take a const char * argument Remove unnecessary variable rtrn in XkbKeysymText AuthAudit: clean up string handling calls LogVMessageVerb: Fix const mismatch warning Convert glx/single2.c:DoGetString() to use asprintf() Remove bad code from DoShowOptions (Xorg -showopts handler) Move DoShowOptions to xf86Configure.c, delete xf86ShowOpts.c Remove xf86FormatPciBusNumber from API, inline the one place its used Convert a bunch of sprintf to snprintf calls Reduce unnecessary string copying in xkbtext routines Mark arguments to fopen/popen/system wrappers as const char * Mark XKB char * as const to clean up gcc -Wwrite-strings warnings sun_agp: cast key to uintptr_t before casting to (int *) Remove redundant redeclarations of functions in the same header file Fix gcc -Wwrite-strings warnings in XkbGetRulesDflts Fix gcc -Wwrite-strings warnings in various extensions FindModule: stop copying const char *dirname to char *dirpath Fix gcc -Wwrite-strings warnings in xf86 ddx Fix gcc -Wwrite-strings warnings in xf86Modes code Limit the number of screens Xvfb will attempt to allocate memory for Disable building of tests requiring DDX functions when Xorg is not built Remove unused function checks from configure.ac include/*.h.in Move to autoconf standard function name checks defines Fix gcc warnings about redundant declarations of fallback functions LoaderOpen returns either a valid pointer or NULL, so don't check for 0 Fix builds of Xnest Xephyr with Solaris Studio compilers Change disable_clientpointer return type to void xf86RegisterRootWindowProperty is confused about xnfcalloc Even more correctly free config file names CheckForEmptyMask does not need to declare int n twice constify strings in resource name registry xres.c: Preserve constness of string returned by LookupResourceName os/access.c: replace acmp acopy macros with memcmp memcpy calls Constify string for authorization protocol names Constify the reason string throughout the authorization check framework OsInit: store /dev/null in a const char * WriteToClient: preserve constness of buf while extracting length value LockServer: store path to LOCKDIR literal string in a const char * xdmcp.c: fix three small const warnings CompareISOLatin1Lowered: constify arguments x86emu: constify debug strings DoShowOptions: preserve constness of options list as we walk it Convert KdDoSwitchCmd to use asprintf instead of malloc/strcat/etc. KdParseFindNext: Constify delim argument XkbFindSrvLedInfo: remove extraneous name-clashing sli variable _XkbFilterDeviceBtn: move variable declarations to match usage scope Remove duplicate declaration of xf86ValidateModesFlags in xf86Modes.h Remove duplicate declarations of KdAdd*Driver in kdrive.h xf86Priv.h: Add some noreturn attributes suggested by gcc Add some printf format attributes suggested by gcc xf86 parser: convert Error to a varargs macro to clear gcc format warnings Include client name if available in PrintDeviceGrabInfo Fix deconstifying cast warning in xi2_get_type Use
[ANNOUNCE] xorg-server 1.11.99.2
Here's the second 1.12 snapshot release. Most of this is cleanups from alanc and preparatory work for the Xi 2.2 integration. It looks like that piece is nearly ready to merge; Peter has put the changes out for review. When that's finished, the merge window will be closed. There are a couple of patch sets which are outstanding today: * Gaetan's changes to the server C flags. I'd like to see some discussion about these as I don't quite get the rational. * Jamey's GC clipping changes. These have been reviewed and are pretty much ready for merging. I looked over them and offered a few comments, but I don't see any reason they can't get merged this week. One week to go... Adam Jackson (1): fbdevhw: iterate over all modes that match a mode. (v3) Alan Coopersmith (69): Fix Xdmx build on Linux to work with strlcpy changes Don't fallback to wsfb or fbdev on Solaris Don't require ld -wrap for tests that don't need it Enable memory checking during unit testing Remove a couple Error() instances left behind by 09dbfcb0ad7b6c8 Fix Sun compiler check that got turned around Add fallback implementation of strndup() Convert some malloc + strncpy pairs into strndup calls Convert AllocXTestDevice to use asprintf Convert strncpy/strncat to strlcpy/strlcat matchDriverFromFiles: use one snprintf instead of strncpy/cat series Convert dmxSetDefaultFontPath to use strdup instead of malloc+strncpy Convert DetermineClientCmd to use strdup instead of malloc+strncpy Convert ProcRenderQueryFilters to use memcpy instead of strncpy Make XIGetKnownProperty take a const char * argument Remove unnecessary variable rtrn in XkbKeysymText AuthAudit: clean up string handling calls LogVMessageVerb: Fix const mismatch warning Convert glx/single2.c:DoGetString() to use asprintf() Remove bad code from DoShowOptions (Xorg -showopts handler) Move DoShowOptions to xf86Configure.c, delete xf86ShowOpts.c Remove xf86FormatPciBusNumber from API, inline the one place its used Convert a bunch of sprintf to snprintf calls Reduce unnecessary string copying in xkbtext routines Mark arguments to fopen/popen/system wrappers as const char * Mark XKB char * as const to clean up gcc -Wwrite-strings warnings sun_agp: cast key to uintptr_t before casting to (int *) Remove redundant redeclarations of functions in the same header file Fix gcc -Wwrite-strings warnings in XkbGetRulesDflts Fix gcc -Wwrite-strings warnings in various extensions FindModule: stop copying const char *dirname to char *dirpath Fix gcc -Wwrite-strings warnings in xf86 ddx Fix gcc -Wwrite-strings warnings in xf86Modes code Limit the number of screens Xvfb will attempt to allocate memory for Disable building of tests requiring DDX functions when Xorg is not built Remove unused function checks from configure.ac include/*.h.in Move to autoconf standard function name checks defines Fix gcc warnings about redundant declarations of fallback functions LoaderOpen returns either a valid pointer or NULL, so don't check for 0 Fix builds of Xnest Xephyr with Solaris Studio compilers Change disable_clientpointer return type to void xf86RegisterRootWindowProperty is confused about xnfcalloc Even more correctly free config file names CheckForEmptyMask does not need to declare int n twice constify strings in resource name registry xres.c: Preserve constness of string returned by LookupResourceName os/access.c: replace acmp acopy macros with memcmp memcpy calls Constify string for authorization protocol names Constify the reason string throughout the authorization check framework OsInit: store /dev/null in a const char * WriteToClient: preserve constness of buf while extracting length value LockServer: store path to LOCKDIR literal string in a const char * xdmcp.c: fix three small const warnings CompareISOLatin1Lowered: constify arguments x86emu: constify debug strings DoShowOptions: preserve constness of options list as we walk it Convert KdDoSwitchCmd to use asprintf instead of malloc/strcat/etc. KdParseFindNext: Constify delim argument XkbFindSrvLedInfo: remove extraneous name-clashing sli variable _XkbFilterDeviceBtn: move variable declarations to match usage scope Remove duplicate declaration of xf86ValidateModesFlags in xf86Modes.h Remove duplicate declarations of KdAdd*Driver in kdrive.h xf86Priv.h: Add some noreturn attributes suggested by gcc Add some printf format attributes suggested by gcc xf86 parser: convert Error to a varargs macro to clear gcc format warnings Include client name if available in PrintDeviceGrabInfo Fix deconstifying cast warning in xi2_get_type Use
[ANNOUNCE] libXi 1.4.4
libXi 1.4.4 comes with two memory fixes that can cause crashes in clients. Commit Handle unknown device classes can only be triggered when libXi 1.4.x runs against the git X server. If the XIQueryDevice() reply contained classes unknown to libXi, we didn't allocate memory for these classes and ended up overwriting valid ones. Commit Fix duplicate sizeof in copy_classes fixes a typo, instead of malloc(X * sizeof(Y)) the code called malloc(sizeof(X * sizeof(Y))). This could lead to memory corruption. Peter Hutterer (8): man: Fix formatting in XGetFeedbackControl man: fix typo in XIQueryDevice man page Handle unknown device classes. man: fix #include for XIGrabButton man: XIGrabButton returns error codes, not status codes man: passive grabs return the number of failed modifier combinations Fix duplicate sizeof in copy_classes libXi 1.4.4 git tag: libXi-1.4.4 http://xorg.freedesktop.org/archive/individual/lib/libXi-1.4.4.tar.bz2 MD5: 299f36c6d6a586ab33aa5c1d97d93078 libXi-1.4.4.tar.bz2 SHA1: e4ca1b45368214ba246bfad398ea087125c79f31 libXi-1.4.4.tar.bz2 SHA256: 939b25914d86496885b41b9e99969757ceed38c0e54e66a3993a269286ab5881 libXi-1.4.4.tar.bz2 http://xorg.freedesktop.org/archive/individual/lib/libXi-1.4.4.tar.gz MD5: 155d57405739a2ec95519116c11c8ee0 libXi-1.4.4.tar.gz SHA1: 72d99a4164b008232632d845a5afa8caecb9f733 libXi-1.4.4.tar.gz SHA256: bfb1cf00567a5a9bc2bd98b06bf77c33d18c48da9a62f2b413979803208384f9 libXi-1.4.4.tar.gz pgpKNdASUswab.pgp Description: PGP signature ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] inputproto 2.1
We haven't had any change requests to the 2.1 protocol changes and the 2.2 changes are about to be done soon too. Time for a release. inputproto contains the protocol specification and header files for the X Input Extension. This release introduces two new features: - smooth scrolling support allows devices to send scroll events through valuator information instead of the traditional button 4-7 clicks. - new raw event behaviour allows clients to listen to raw events from a device even if that device is currently grabbed For a description of the changes, see http://who-t.blogspot.com/2011/09/whats-new-in-xi-21-smooth-scrolling.html http://who-t.blogspot.com/2011/09/whats-new-in-xi-21-raw-events.html http://who-t.blogspot.com/2011/09/whats-new-in-xi-21-xi2-defines.html http://who-t.blogspot.com/2011/09/whats-new-in-xi-21-versioning.html Other changes include packaging fixes and miscellaneous fixes. Below is the full changelog since 2.0. Alexandre Julliard (1): XI2.h: Fix off-by-one error in the XIMaskLen definition. Chase Douglas (1): Include stdint.h Daniel Stone (2): Add XIPointerEmulated for emulated events Document smooth-scrolling support Fernando Carrijo (1): Fix typos in XIproto.txt Gaetan Nadon (14): .gitignore: use common defaults with custom section # 24239 configure.ac: AM_MAINTAINER_MODE missing #24238 configure.ac: deploy the new XORG_DEFAULT_OPTIONS #24242 Makefile.am: INSTALL file is missing or incorrect #24206 Makefile.am: ChangeLog not required: EXTRA_DIST or *CLEANFILES #24432 README: file created or updated #24206 Makefile.am: add ChangeLog and INSTALL on MAINTAINERCLEANFILES Add Red Had Copyright in the COPYING file. config: install and distribute XI2proto.txt XIproto.txt config: remove the pkgconfig pc.in file from EXTRA_DIST config: update AC_PREREQ statement to 2.60 specs: convert XI2proto.txt to html using asciidoc XI2proto.txt: fix whitespace issues XIproto.txt: fix whitespace issues Peter Hutterer (26): XI2proto.txt: fix up some request names. Define the error cases for XSetDeviceMode better. Spell out event types for XIDeviceEvent. Typo fix: GrabTypeFocusIn - GrabtypeFocusIn inputproto 2.0.1 Add minimal asciidoc syntax specs: move erroneous Errors: line to where it belongs specs: enable asciidoc parsing for XIproto.txt Add XI2-specific defines for grab and property requests Provide convenience defines for owner_events. specs: add a linebreak for asciidoc parsing Put a warning in about not adding any further libXi defines specs: ValuatorClass includes a mode specs: fix two typos in XI2proto.txt Bump to 2.0.99 Announce 2.1 availability through the XI_2_Major and XI_2_Minor defines XI2.1: send RawEvents at all times. Add sourceid to RawEvents (#34420) Move scroll information into a new class. inputproto 2.0.99.1 (first snapshot of 2.1) specs: clarify that Preferred scroll valuators are per scroll direction specs: We're up to version 2.1 now, say so specs: scroll events have no specific event type, state so. specs: smooth scrolling was added in 2.1, say so specs: typo fix inputproto 2.1 git tag: inputproto-2.1 http://xorg.freedesktop.org/archive/individual/proto/inputproto-2.1.tar.bz2 MD5: c4973f2e65a0ff9a283e665b31b96bb7 inputproto-2.1.tar.bz2 SHA1: 67b2c5af588d21a7dad2d60f9d3b1d148edb9d36 inputproto-2.1.tar.bz2 SHA256: b317361cdd09d79ba27f13d4e08adc793db27b491c4d513729e0d0312139 inputproto-2.1.tar.bz2 http://xorg.freedesktop.org/archive/individual/proto/inputproto-2.1.tar.gz MD5: ba094ac09ddfcc4d3381193c2f189d80 inputproto-2.1.tar.gz SHA1: 9beeb9c29034d88fd35a7bd46c668f6781067661 inputproto-2.1.tar.gz SHA256: 02b35778bf4e2cb2a9b2c14a0c42e04180b71890fd7fcd371643c5f3d4df3467 inputproto-2.1.tar.gz pgpBCogKKGdA9.pgp Description: PGP signature ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
Re: help with xorg.conf
Hi Alan, Thanks for the info, that fixed the first problem. I had assumed that Xorg was looking in the config dir listed in the Xorg log, which was obviously a poor assumption. Thanks again, James On Wed, Dec 14, 2011 at 8:11 PM, Alan Coopersmith alan.coopersm...@oracle.com wrote: On 12/14/11 14:08, James Strother wrote: Problem 1: Unable to access config file at non-default location as non-root - This seems like an extremely simple problem, but I'm stumped. I have written an alt.conf file, and place it into /etc/X11/xorg.conf.d. The file exists, is owned by root, and has permissions of 644. It shows up on ls just fine: $ ls /etc/X11/xorg.conf.d alt.conf But I can't actually get Xorg to find or use that file: $ Xorg :1 -config alt.conf /etc/X11/xorg.conf.d is not the location for alternate configuration files - it's used for config file fragments to be used by *ALL* Xorg instances run on the system. The xorg.conf man page lists the directories you can put alternate configuration files in (I just noticed that Xorg(1) man page does not, though it does point you off to the xorg.conf man page for the full list). For instance, for testing, I have a /etc/X11/xorg.conf.dummy config file that loads the dummy driver, which I can run with Xorg -config xorg.conf.dummy, and in our OS packages, we ship /usr/lib/X11/xorg.conf.vesa so that the OS installer can run Xorg -config xorg.conf.vesa when the normal drivers fail on the LiveCD and the user chooses the VESA mode option from the grub menu instead. I expected this to connect to the graphics card at PCI:12:0:0 in order to create a one monitor screen. However, Xorg actually connects to both cards and then only displays on the graphics card at PCI:8:0:0. I have tried setting AutoAddDevices/AutoEnableDevices to false in ServerFlags without success. The AutoAddDevices/AutoEnableDevices flags only apply to input devices not video cards. (I can't explain the rest of your issue here, just that bit.) -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ 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
[ANNOUNCE] libXi 1.4.4
libXi 1.4.4 comes with two memory fixes that can cause crashes in clients. Commit Handle unknown device classes can only be triggered when libXi 1.4.x runs against the git X server. If the XIQueryDevice() reply contained classes unknown to libXi, we didn't allocate memory for these classes and ended up overwriting valid ones. Commit Fix duplicate sizeof in copy_classes fixes a typo, instead of malloc(X * sizeof(Y)) the code called malloc(sizeof(X * sizeof(Y))). This could lead to memory corruption. Peter Hutterer (8): man: Fix formatting in XGetFeedbackControl man: fix typo in XIQueryDevice man page Handle unknown device classes. man: fix #include for XIGrabButton man: XIGrabButton returns error codes, not status codes man: passive grabs return the number of failed modifier combinations Fix duplicate sizeof in copy_classes libXi 1.4.4 git tag: libXi-1.4.4 http://xorg.freedesktop.org/archive/individual/lib/libXi-1.4.4.tar.bz2 MD5: 299f36c6d6a586ab33aa5c1d97d93078 libXi-1.4.4.tar.bz2 SHA1: e4ca1b45368214ba246bfad398ea087125c79f31 libXi-1.4.4.tar.bz2 SHA256: 939b25914d86496885b41b9e99969757ceed38c0e54e66a3993a269286ab5881 libXi-1.4.4.tar.bz2 http://xorg.freedesktop.org/archive/individual/lib/libXi-1.4.4.tar.gz MD5: 155d57405739a2ec95519116c11c8ee0 libXi-1.4.4.tar.gz SHA1: 72d99a4164b008232632d845a5afa8caecb9f733 libXi-1.4.4.tar.gz SHA256: bfb1cf00567a5a9bc2bd98b06bf77c33d18c48da9a62f2b413979803208384f9 libXi-1.4.4.tar.gz pgpMKRfNK7dqD.pgp Description: PGP signature ___ 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
[ANNOUNCE] inputproto 2.1
We haven't had any change requests to the 2.1 protocol changes and the 2.2 changes are about to be done soon too. Time for a release. inputproto contains the protocol specification and header files for the X Input Extension. This release introduces two new features: - smooth scrolling support allows devices to send scroll events through valuator information instead of the traditional button 4-7 clicks. - new raw event behaviour allows clients to listen to raw events from a device even if that device is currently grabbed For a description of the changes, see http://who-t.blogspot.com/2011/09/whats-new-in-xi-21-smooth-scrolling.html http://who-t.blogspot.com/2011/09/whats-new-in-xi-21-raw-events.html http://who-t.blogspot.com/2011/09/whats-new-in-xi-21-xi2-defines.html http://who-t.blogspot.com/2011/09/whats-new-in-xi-21-versioning.html Other changes include packaging fixes and miscellaneous fixes. Below is the full changelog since 2.0. Alexandre Julliard (1): XI2.h: Fix off-by-one error in the XIMaskLen definition. Chase Douglas (1): Include stdint.h Daniel Stone (2): Add XIPointerEmulated for emulated events Document smooth-scrolling support Fernando Carrijo (1): Fix typos in XIproto.txt Gaetan Nadon (14): .gitignore: use common defaults with custom section # 24239 configure.ac: AM_MAINTAINER_MODE missing #24238 configure.ac: deploy the new XORG_DEFAULT_OPTIONS #24242 Makefile.am: INSTALL file is missing or incorrect #24206 Makefile.am: ChangeLog not required: EXTRA_DIST or *CLEANFILES #24432 README: file created or updated #24206 Makefile.am: add ChangeLog and INSTALL on MAINTAINERCLEANFILES Add Red Had Copyright in the COPYING file. config: install and distribute XI2proto.txt XIproto.txt config: remove the pkgconfig pc.in file from EXTRA_DIST config: update AC_PREREQ statement to 2.60 specs: convert XI2proto.txt to html using asciidoc XI2proto.txt: fix whitespace issues XIproto.txt: fix whitespace issues Peter Hutterer (26): XI2proto.txt: fix up some request names. Define the error cases for XSetDeviceMode better. Spell out event types for XIDeviceEvent. Typo fix: GrabTypeFocusIn - GrabtypeFocusIn inputproto 2.0.1 Add minimal asciidoc syntax specs: move erroneous Errors: line to where it belongs specs: enable asciidoc parsing for XIproto.txt Add XI2-specific defines for grab and property requests Provide convenience defines for owner_events. specs: add a linebreak for asciidoc parsing Put a warning in about not adding any further libXi defines specs: ValuatorClass includes a mode specs: fix two typos in XI2proto.txt Bump to 2.0.99 Announce 2.1 availability through the XI_2_Major and XI_2_Minor defines XI2.1: send RawEvents at all times. Add sourceid to RawEvents (#34420) Move scroll information into a new class. inputproto 2.0.99.1 (first snapshot of 2.1) specs: clarify that Preferred scroll valuators are per scroll direction specs: We're up to version 2.1 now, say so specs: scroll events have no specific event type, state so. specs: smooth scrolling was added in 2.1, say so specs: typo fix inputproto 2.1 git tag: inputproto-2.1 http://xorg.freedesktop.org/archive/individual/proto/inputproto-2.1.tar.bz2 MD5: c4973f2e65a0ff9a283e665b31b96bb7 inputproto-2.1.tar.bz2 SHA1: 67b2c5af588d21a7dad2d60f9d3b1d148edb9d36 inputproto-2.1.tar.bz2 SHA256: b317361cdd09d79ba27f13d4e08adc793db27b491c4d513729e0d0312139 inputproto-2.1.tar.bz2 http://xorg.freedesktop.org/archive/individual/proto/inputproto-2.1.tar.gz MD5: ba094ac09ddfcc4d3381193c2f189d80 inputproto-2.1.tar.gz SHA1: 9beeb9c29034d88fd35a7bd46c668f6781067661 inputproto-2.1.tar.gz SHA256: 02b35778bf4e2cb2a9b2c14a0c42e04180b71890fd7fcd371643c5f3d4df3467 inputproto-2.1.tar.gz pgpcn2NFlTTUF.pgp Description: PGP signature ___ 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
relation between kernel input events and leds
This might not be 100% on-topic for this list, but it's the closest list I'm familiar with. I've got a mouse without a horizontal wheel. I've came across a piece of code, that was written for for emulating mouse buttons via keyboard. It grabs input/event* nodes and uses uinput to substitute certain mouse/keyboard combinations for the desired mouse buttons. I've modified it to use shift+wheel as hwheel. It worked, but there's one unfortunate side effect, I just can't fix. Both in console and in X pressing CapsLock/Numlock toggles its state, but not the relevant keyboard led. The original code comes from something called mouseemu, but I've taken 0.15 of it and applied *some* of the Debian patches (then added some of my own chages - I'm near the point of a working libudev hotplug monitor), so it differs in a few places. Now, my question is: what is so special about keyboard led events, that they don't get toggled, even though the states do ? Is it something about timing/order of events ? Do I need to read and process a certain number of events in one go ? ___ 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: help with xorg.conf
On 12/14/11 14:08, James Strother wrote: Problem 1: Unable to access config file at non-default location as non-root - This seems like an extremely simple problem, but I'm stumped. I have written an alt.conf file, and place it into /etc/X11/xorg.conf.d. The file exists, is owned by root, and has permissions of 644. It shows up on ls just fine: $ ls /etc/X11/xorg.conf.d alt.conf But I can't actually get Xorg to find or use that file: $ Xorg :1 -config alt.conf /etc/X11/xorg.conf.d is not the location for alternate configuration files - it's used for config file fragments to be used by *ALL* Xorg instances run on the system. The xorg.conf man page lists the directories you can put alternate configuration files in (I just noticed that Xorg(1) man page does not, though it does point you off to the xorg.conf man page for the full list). For instance, for testing, I have a /etc/X11/xorg.conf.dummy config file that loads the dummy driver, which I can run with Xorg -config xorg.conf.dummy, and in our OS packages, we ship /usr/lib/X11/xorg.conf.vesa so that the OS installer can run Xorg -config xorg.conf.vesa when the normal drivers fail on the LiveCD and the user chooses the VESA mode option from the grub menu instead. I expected this to connect to the graphics card at PCI:12:0:0 in order to create a one monitor screen. However, Xorg actually connects to both cards and then only displays on the graphics card at PCI:8:0:0. I have tried setting AutoAddDevices/AutoEnableDevices to false in ServerFlags without success. The AutoAddDevices/AutoEnableDevices flags only apply to input devices not video cards. (I can't explain the rest of your issue here, just that bit.) -- -Alan Coopersmith-alan.coopersm...@oracle.com Oracle Solaris Platform Engineering: X Window System ___ 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
[ANNOUNCE] libdrm 2.4.29
This publishes some new API for Intel to be able to cap the number of VMA that libdrm_intel caches amongst its bo. This is intended to be used by clients to prevent applications (such as the xserver) from exhausting their per-process limits on inactive GTT mmaps whilst also mitigating against the costs of recreating those mmaps. -Chris Chris Wilson (6): intel: Clean up mmaps on freeing the buffer intel: Add an interface to limit vma caching intel: Evict cached VMA in order to make room for new mappings intel: Update map-count for an early error return during mapping intel: Remove the fresh assertions used to debug the vma cacheing configure: Bump version for 2.4.29 Dave Airlie (1): test/radeon: add missing files for dist git tag: 2.4.29 http://dri.freedesktop.org/libdrm/libdrm-2.4.29.tar.bz2 MD5: 96d5e3e9edd55f4b016fe3b5dd0a1953 libdrm-2.4.29.tar.bz2 SHA1: 054ca4f6b9145b1bb5192f3cba4dd1835fcc5977 libdrm-2.4.29.tar.bz2 SHA256: e2432dc93e933479132123a1dca382294c30f55bc895bb737b6bdd6f2b8c452e libdrm-2.4.29.tar.bz2 http://dri.freedesktop.org/libdrm/libdrm-2.4.29.tar.gz MD5: 2596e48b4d2663ed075f0a86e977cf99 libdrm-2.4.29.tar.gz SHA1: 68d46937f5e725b439a8ed748211f0a27168caf3 libdrm-2.4.29.tar.gz SHA256: d60ecf6fc52f92663ee80cc94560ead56b493e4b91d1ee99f2292f7ecdab40b2 libdrm-2.4.29.tar.gz -- Chris Wilson, Intel Open Source Technology Centre signature.asc Description: Digital signature ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] inputproto 2.1.99.3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chase Douglas (3): Touch IDs must be globally unique State that future touch IDs are indeterminate inputproto 2.1.99.3 Peter Hutterer (1): Remove XI2.1 and XI2.2 warnings and errors git tag: inputproto-2.1.99.3 http://xorg.freedesktop.org/archive/individual/proto/inputproto-2.1.99.3.tar.bz2 MD5: dd62927a5cbcd554b0296969e6ee5a26 inputproto-2.1.99.3.tar.bz2 SHA1: 726d63755aa2d72fbf548cd583c8aff29aae529a inputproto-2.1.99.3.tar.bz2 SHA256: 547690b27c059aefa7b4e9f0ffc980cedde62009acced925faf816a86ff03483 inputproto-2.1.99.3.tar.bz2 http://xorg.freedesktop.org/archive/individual/proto/inputproto-2.1.99.3.tar.gz MD5: 62b8ae147483d2e52820801f6a263be7 inputproto-2.1.99.3.tar.gz SHA1: ac5bd3ef4920b44f6c2d22357729a2c2ddc31471 inputproto-2.1.99.3.tar.gz SHA256: 35e31f1050a050ed121fc77e231eab91a4bf7e9ecd4756f832d0b173391c4469 inputproto-2.1.99.3.tar.gz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJO5559AAoJEI3Z6a9pX7cqxgsP/3RFM+MNo2BIDOh2d4iie8ac gWWSYBmnC/Zb3EEop5wUfGYUAbw6FmANL9af/QFX728HvVvakAwtrEN85XcUl91S 3V+5qBoXMAgr727xozTfKoH90DzNJ5884iBOR9wpuLLLwK7+9DtWUdQ5/I7ErPpF T5St/tajGOyzgu4RI2CYU7CyRejhzhlymkX4Z1b+GdDevSHDJwJBd82oCcXi4GMy 09QmCEVashOmDF8+7/+92Dsa8QXzIBJsUIj/lk2LlAKGLhWCrGSSUYtuLUkgQHcH 35bEaIhPwDauFxnbqfrw5zbZMK7Mh2BomZ9D/kcFbb+0wa+QALI1fb4xhV6fyxAO NARmuyl7V4CA9oZCuAYgn+5EBW6ornpnpKR1PAPREpYcHhrRwKlJ48QT19S7cQ7o 62p6oMQvtqqAyEjob4BP1f1I6LGIlaLO/Z6Z9zKwc/zbosYGC4QdswhPr6EkMkUP qTjasuh5LEAosNmHEMmXEXhp3zDkHxKD+D7Mi2m2XCt100m6HjU9zcWIcLF+OOXJ wLu678S7d1wQjasAsxlh0zcRk3fp8vrIfGbh9HFGFTGKd555HDSTGyzSwp42ZFn5 cx7lAdx9XgNmK0HeB3W6AErTniIUoyw4pjHAl4yVi56nU33YcDy7CTcY5DJO2RaT 31UDfUNpBSlkOndcD4ux =WIYc -END PGP SIGNATURE- ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
[ANNOUNCE] inputproto 2.1.99.3
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Chase Douglas (3): Touch IDs must be globally unique State that future touch IDs are indeterminate inputproto 2.1.99.3 Peter Hutterer (1): Remove XI2.1 and XI2.2 warnings and errors git tag: inputproto-2.1.99.3 http://xorg.freedesktop.org/archive/individual/proto/inputproto-2.1.99.3.tar.bz2 MD5: dd62927a5cbcd554b0296969e6ee5a26 inputproto-2.1.99.3.tar.bz2 SHA1: 726d63755aa2d72fbf548cd583c8aff29aae529a inputproto-2.1.99.3.tar.bz2 SHA256: 547690b27c059aefa7b4e9f0ffc980cedde62009acced925faf816a86ff03483 inputproto-2.1.99.3.tar.bz2 http://xorg.freedesktop.org/archive/individual/proto/inputproto-2.1.99.3.tar.gz MD5: 62b8ae147483d2e52820801f6a263be7 inputproto-2.1.99.3.tar.gz SHA1: ac5bd3ef4920b44f6c2d22357729a2c2ddc31471 inputproto-2.1.99.3.tar.gz SHA256: 35e31f1050a050ed121fc77e231eab91a4bf7e9ecd4756f832d0b173391c4469 inputproto-2.1.99.3.tar.gz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQIcBAEBAgAGBQJO5559AAoJEI3Z6a9pX7cqxgsP/3RFM+MNo2BIDOh2d4iie8ac gWWSYBmnC/Zb3EEop5wUfGYUAbw6FmANL9af/QFX728HvVvakAwtrEN85XcUl91S 3V+5qBoXMAgr727xozTfKoH90DzNJ5884iBOR9wpuLLLwK7+9DtWUdQ5/I7ErPpF T5St/tajGOyzgu4RI2CYU7CyRejhzhlymkX4Z1b+GdDevSHDJwJBd82oCcXi4GMy 09QmCEVashOmDF8+7/+92Dsa8QXzIBJsUIj/lk2LlAKGLhWCrGSSUYtuLUkgQHcH 35bEaIhPwDauFxnbqfrw5zbZMK7Mh2BomZ9D/kcFbb+0wa+QALI1fb4xhV6fyxAO NARmuyl7V4CA9oZCuAYgn+5EBW6ornpnpKR1PAPREpYcHhrRwKlJ48QT19S7cQ7o 62p6oMQvtqqAyEjob4BP1f1I6LGIlaLO/Z6Z9zKwc/zbosYGC4QdswhPr6EkMkUP qTjasuh5LEAosNmHEMmXEXhp3zDkHxKD+D7Mi2m2XCt100m6HjU9zcWIcLF+OOXJ wLu678S7d1wQjasAsxlh0zcRk3fp8vrIfGbh9HFGFTGKd555HDSTGyzSwp42ZFn5 cx7lAdx9XgNmK0HeB3W6AErTniIUoyw4pjHAl4yVi56nU33YcDy7CTcY5DJO2RaT 31UDfUNpBSlkOndcD4ux =WIYc -END PGP SIGNATURE- ___ 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: evdev input module and multiple X screen support
Peter, I have been looking at this for a while and have not been able to get my system setup correctly as it is a rather complex setup. I have 4 monitors on this system. The first one is NOT a touch screen and is at 800X600, the other 3 are touch screens at 1280X1024, with the center of those 3 rotated to portrait mode. I am not quite sure how to proceed looking at the examples provided since none of them really give me any idea of what to do about my first monitor which is not a touch device. I am assuming that I still need to account for it in the equations, is that a valid assumption? #xinput list â¡ Virtual core pointer id=2[master pointer (3)] â â³ Virtual core XTEST pointer id=4[slave pointer (2)] â â³ TouchScreenLeft id=6[slave pointer (2)] â â³ TouchScreenCenterid=7[slave pointer (2)] â â³ TouchScreenRight id=8[slave pointer (2)] ⣠Virtual core keyboardid=3[master keyboard (2)] â³ Virtual core XTEST keyboard id=5[slave keyboard (3)] â³ Power Button id=9[slave keyboard (3)] â³ Power Button id=10 [slave keyboard (3)] â³ Logitech USB Keyboardid=11 [slave keyboard (3)] â³ Logitech USB Keyboardid=12 [slave keyboard (3)] #xinput list-props TouchScreenLeft Device 'TouchScreenLeft': Device Enabled (117): 1 Coordinate Transformation Matrix (119): 1.00, 0.00, 0.00, 0.00, 1.00, 0.00, 0.00, 0.00, 1.00 #xinput list-props TouchScreenCenter Device 'TouchScreenCenter': Device Enabled (117): 1 Coordinate Transformation Matrix (119): 1.00, 0.00, 0.00, 0.00, 1.00, 0.00, 0.00, 0.00, 1.00 #xinput list-props TouchScreenRight Device 'TouchScreenRight': Device Enabled (117): 1 Coordinate Transformation Matrix (119): 1.00, 0.00, 0.00, 0.00, 1.00, 0.00, 0.00, 0.00, 1.00 So first to make it a little easier no rotation for now on #2: 0: 800/(800 + (3*1280) ) 00 0 600/1024 0 0 0 1 1: 1280/(800 + (3*1280) ) 0 800/(800 + (3*1280) ) 0 1024/10240 0 01 2: 1280/(800 + (3*1280) ) 0 800+1280/(800 + (3*1280) ) 0 1024/1024 0 0 0 1 3: 1280/(800 + (3*1280) ) 0 800 + (2*1280)/(800 + (3*1280) ) 0 1024/1024 0 0 0 1 Does that look about correct, because the math on the 3rd number or c2 from the equation examples does not seem to add up properly to equal a total of 1. Regards, Curtis On 09.12.2011 23:37, Peter Hutterer wrote: On Fri, Dec 09, 2011 at 12:47:10PM -0500, Curtis Rubel wrote: Hello xorg... Can someone tell me if multiple X screen support is planned for the evdev input module? We have a number of multiple X screen systems here running Xorg using the older evtouch input library and from what I can see it appears this module is no longer supported and being replaced by the evdev module. Is this the case or has the evtouch input library just not been updated yet?? Any help in this matter would be greatly appreciated...as the touch screen vendor ELO does not support multiple USB touchscreens on a single system... input drivers don't do multi-screen handling (anymore), it's all handled by the server now. See the documentation here: http://wiki.x.org/wiki/XInputCoordinateTransformationMatrixUsage Cheers, Peter -- Curtis Rubel Senior Development Engineer Compro Computer Services, Inc. 105 East Drive - Melbourne, Florida, 32904 Phone: 321-727-2211 email: cru...@compro.net Web: http://www.compro.net An ISO 9001:2008 Registered Company --- CONFIDENTIALITY NOTICE: This email transmission, and any documents, files or previous email messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify the sender by email or call 321-727-2211. Please destroy the original transmission and its attachments without reading or saving it in any manner. ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info:
Re: evdev input module and multiple X screen support
Peter, I did attempt to try setting the values to those I sent you below and when I touch any of the touch screens, my cursor still remains in the first monitor screen and I never see it move to any of the other 3 touch monitors. Is there something else I need to do other than set the xinput settings to get the new settings to take effect? Regards, Curtis On 12.12.2011 09:02, Curtis Rubel wrote: Peter, I have been looking at this for a while and have not been able to get my system setup correctly as it is a rather complex setup. I have 4 monitors on this system. The first one is NOT a touch screen and is at 800X600, the other 3 are touch screens at 1280X1024, with the center of those 3 rotated to portrait mode. I am not quite sure how to proceed looking at the examples provided since none of them really give me any idea of what to do about my first monitor which is not a touch device. I am assuming that I still need to account for it in the equations, is that a valid assumption? #xinput list â¡ Virtual core pointer id=2[master pointer (3)] â â³ Virtual core XTEST pointer id=4[slave pointer (2)] â â³ TouchScreenLeft id=6[slave pointer (2)] â â³ TouchScreenCenterid=7[slave pointer (2)] â â³ TouchScreenRight id=8[slave pointer (2)] ⣠Virtual core keyboardid=3[master keyboard (2)] â³ Virtual core XTEST keyboard id=5[slave keyboard (3)] â³ Power Button id=9[slave keyboard (3)] â³ Power Button id=10 [slave keyboard (3)] â³ Logitech USB Keyboardid=11 [slave keyboard (3)] â³ Logitech USB Keyboardid=12 [slave keyboard (3)] #xinput list-props TouchScreenLeft Device 'TouchScreenLeft': Device Enabled (117): 1 Coordinate Transformation Matrix (119): 1.00, 0.00, 0.00, 0.00, 1.00, 0.00, 0.00, 0.00, 1.00 #xinput list-props TouchScreenCenter Device 'TouchScreenCenter': Device Enabled (117): 1 Coordinate Transformation Matrix (119): 1.00, 0.00, 0.00, 0.00, 1.00, 0.00, 0.00, 0.00, 1.00 #xinput list-props TouchScreenRight Device 'TouchScreenRight': Device Enabled (117): 1 Coordinate Transformation Matrix (119): 1.00, 0.00, 0.00, 0.00, 1.00, 0.00, 0.00, 0.00, 1.00 So first to make it a little easier no rotation for now on #2: 0: 800/(800 + (3*1280) ) 00 0 600/1024 0 0 0 1 1: 1280/(800 + (3*1280) ) 0 800/(800 + (3*1280) ) 0 1024/10240 0 01 2: 1280/(800 + (3*1280) ) 0 800+1280/(800 + (3*1280) ) 0 1024/1024 0 0 0 1 3: 1280/(800 + (3*1280) ) 0 800 + (2*1280)/(800 + (3*1280) ) 0 1024/1024 0 0 0 1 Does that look about correct, because the math on the 3rd number or c2 from the equation examples does not seem to add up properly to equal a total of 1. Regards, Curtis On 09.12.2011 23:37, Peter Hutterer wrote: On Fri, Dec 09, 2011 at 12:47:10PM -0500, Curtis Rubel wrote: Hello xorg... Can someone tell me if multiple X screen support is planned for the evdev input module? We have a number of multiple X screen systems here running Xorg using the older evtouch input library and from what I can see it appears this module is no longer supported and being replaced by the evdev module. Is this the case or has the evtouch input library just not been updated yet?? Any help in this matter would be greatly appreciated...as the touch screen vendor ELO does not support multiple USB touchscreens on a single system... input drivers don't do multi-screen handling (anymore), it's all handled by the server now. See the documentation here: http://wiki.x.org/wiki/XInputCoordinateTransformationMatrixUsage Cheers, Peter -- Curtis Rubel Senior Development Engineer Compro Computer Services, Inc. 105 East Drive - Melbourne, Florida, 32904 Phone: 321-727-2211 email: cru...@compro.net Web: http://www.compro.net An ISO 9001:2008 Registered Company --- CONFIDENTIALITY NOTICE: This email transmission, and any documents, files or previous email messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of any of the information contained in or attached to this transmission is STRICTLY
Re: evdev input module and multiple X screen support
On Mon, Dec 12, 2011 at 09:02:29AM -0500, Curtis Rubel wrote: Peter, I have been looking at this for a while and have not been able to get my system setup correctly as it is a rather complex setup. I have 4 monitors on this system. The first one is NOT a touch screen and is at 800X600, the other 3 are touch screens at 1280X1024, with the center of those 3 rotated to portrait mode. I am not quite sure how to proceed looking at the examples provided since none of them really give me any idea of what to do about my first monitor which is not a touch device. you only set the matrix if you want a input device bound to an _area_ on the screen. so don't think of it in terms of monitors, think of it in terms of touchscreens - the first touchscreen should be mapped to area of the the second monitor from the left, etc. I am assuming that I still need to account for it in the equations, is that a valid assumption? #xinput list â¡ Virtual core pointer id=2[master pointer (3)] â â³ Virtual core XTEST pointer id=4[slave pointer (2)] â â³ TouchScreenLeft id=6[slave pointer (2)] â â³ TouchScreenCenterid=7[slave pointer (2)] â â³ TouchScreenRight id=8[slave pointer (2)] ⣠Virtual core keyboardid=3[master keyboard (2)] â³ Virtual core XTEST keyboard id=5[slave keyboard (3)] â³ Power Button id=9[slave keyboard (3)] â³ Power Button id=10 [slave keyboard (3)] â³ Logitech USB Keyboardid=11 [slave keyboard (3)] â³ Logitech USB Keyboardid=12 [slave keyboard (3)] #xinput list-props TouchScreenLeft Device 'TouchScreenLeft': Device Enabled (117): 1 Coordinate Transformation Matrix (119): 1.00, 0.00, 0.00, 0.00, 1.00, 0.00, 0.00, 0.00, 1.00 #xinput list-props TouchScreenCenter Device 'TouchScreenCenter': Device Enabled (117): 1 Coordinate Transformation Matrix (119): 1.00, 0.00, 0.00, 0.00, 1.00, 0.00, 0.00, 0.00, 1.00 #xinput list-props TouchScreenRight Device 'TouchScreenRight': Device Enabled (117): 1 Coordinate Transformation Matrix (119): 1.00, 0.00, 0.00, 0.00, 1.00, 0.00, 0.00, 0.00, 1.00 So first to make it a little easier no rotation for now on #2: 0: 800/(800 + (3*1280) ) 00 0 600/1024 0 0 0 1 1: 1280/(800 + (3*1280) ) 0 800/(800 + (3*1280) ) 0 1024/10240 0 01 2: 1280/(800 + (3*1280) ) 0 800+1280/(800 + (3*1280) ) 0 1024/1024 0 0 0 1 3: 1280/(800 + (3*1280) ) 0 800 + (2*1280)/(800 + (3*1280) ) 0 1024/1024 0 0 0 1 Does that look about correct, because the math on the 3rd number or c2 from the equation examples does not seem to add up properly to equal a total of 1. I can't see anything wrong at a quick glance, though I suggest just trying with simple values (e.g. 0.5) first to make sure the mapping works at all (see below). c2 shouldn't usually add up to 1 since that'd be an offset of the display width - i don't think there's a use-case for that :) for the right-most screen, usually you'd want c0 + c2 to add up to 1. also, something I forgot in the first email: the matrix only works properly for RandR displays if you're using a released server version, only the git version supports this for traditional multihead. Cheers, Peter On 09.12.2011 23:37, Peter Hutterer wrote: On Fri, Dec 09, 2011 at 12:47:10PM -0500, Curtis Rubel wrote: Hello xorg... Can someone tell me if multiple X screen support is planned for the evdev input module? We have a number of multiple X screen systems here running Xorg using the older evtouch input library and from what I can see it appears this module is no longer supported and being replaced by the evdev module. Is this the case or has the evtouch input library just not been updated yet?? Any help in this matter would be greatly appreciated...as the touch screen vendor ELO does not support multiple USB touchscreens on a single system... input drivers don't do multi-screen handling (anymore), it's all handled by the server now. See the documentation here: http://wiki.x.org/wiki/XInputCoordinateTransformationMatrixUsage Cheers, Peter -- Curtis Rubel Senior Development Engineer Compro Computer Services, Inc. 105 East Drive - Melbourne, Florida, 32904 Phone: 321-727-2211 email: cru...@compro.net Web: http://www.compro.net An ISO
Re: evdev input module and multiple X screen support
Peter, What I am seeing when I run with the settings I sent you below, is that the cursor actually stays in the first monitor. However it appear to be scaled so that as I touch the other 3 touch screens the cursor will move further and further right until I am finally on my last touch screen and the cursor arrow finally can reach the rightmost side of the first monitor. My release of Xorg shows as: X.Org X Server 1.10.4 Release Date: 2011-08-19 from the Xorg.0.log file... So I guess from that information can you determine if I can actually do what I need to do with the version I have installed from the OpenSuSE 12.1 release? Will I need to download from git, build and install that version? Or will it even support separate X screens at all and will I need to switch into a Xinerama type setup? I really appreciate all your help and insight into this.having to switch from an easy method where the input driver would do this for us to this new way is a little bit confusing for me. Best Regards, Curtis On 12.12.2011 16:23, Peter Hutterer wrote: On Mon, Dec 12, 2011 at 09:02:29AM -0500, Curtis Rubel wrote: Peter, I have been looking at this for a while and have not been able to get my system setup correctly as it is a rather complex setup. I have 4 monitors on this system. The first one is NOT a touch screen and is at 800X600, the other 3 are touch screens at 1280X1024, with the center of those 3 rotated to portrait mode. I am not quite sure how to proceed looking at the examples provided since none of them really give me any idea of what to do about my first monitor which is not a touch device. you only set the matrix if you want a input device bound to an _area_ on the screen. so don't think of it in terms of monitors, think of it in terms of touchscreens - the first touchscreen should be mapped to area of the the second monitor from the left, etc. I am assuming that I still need to account for it in the equations, is that a valid assumption? #xinput list â¡ Virtual core pointer id=2[master pointer (3)] â â³ Virtual core XTEST pointer id=4[slave pointer (2)] â â³ TouchScreenLeft id=6[slave pointer (2)] â â³ TouchScreenCenterid=7[slave pointer (2)] â â³ TouchScreenRight id=8[slave pointer (2)] ⣠Virtual core keyboardid=3[master keyboard (2)] â³ Virtual core XTEST keyboard id=5[slave keyboard (3)] â³ Power Button id=9[slave keyboard (3)] â³ Power Button id=10 [slave keyboard (3)] â³ Logitech USB Keyboardid=11 [slave keyboard (3)] â³ Logitech USB Keyboardid=12 [slave keyboard (3)] #xinput list-props TouchScreenLeft Device 'TouchScreenLeft': Device Enabled (117): 1 Coordinate Transformation Matrix (119): 1.00, 0.00, 0.00, 0.00, 1.00, 0.00, 0.00, 0.00, 1.00 #xinput list-props TouchScreenCenter Device 'TouchScreenCenter': Device Enabled (117): 1 Coordinate Transformation Matrix (119): 1.00, 0.00, 0.00, 0.00, 1.00, 0.00, 0.00, 0.00, 1.00 #xinput list-props TouchScreenRight Device 'TouchScreenRight': Device Enabled (117): 1 Coordinate Transformation Matrix (119): 1.00, 0.00, 0.00, 0.00, 1.00, 0.00, 0.00, 0.00, 1.00 So first to make it a little easier no rotation for now on #2: 0: 800/(800 + (3*1280) ) 00 0 600/1024 0 0 0 1 1: 1280/(800 + (3*1280) ) 0 800/(800 + (3*1280) ) 0 1024/10240 0 01 2: 1280/(800 + (3*1280) ) 0 800+1280/(800 + (3*1280) ) 0 1024/1024 0 0 0 1 3: 1280/(800 + (3*1280) ) 0 800 + (2*1280)/(800 + (3*1280) ) 0 1024/1024 0 0 0 1 Does that look about correct, because the math on the 3rd number or c2 from the equation examples does not seem to add up properly to equal a total of 1. I can't see anything wrong at a quick glance, though I suggest just trying with simple values (e.g. 0.5) first to make sure the mapping works at all (see below). c2 shouldn't usually add up to 1 since that'd be an offset of the display width - i don't think there's a use-case for that :) for the right-most screen, usually you'd want c0 + c2 to add up to 1. also, something I forgot in the first email: the matrix only works properly for RandR displays if you're using a released server version, only the git version supports this for traditional multihead. Cheers, Peter On 09.12.2011 23:37, Peter Hutterer wrote: On Fri, Dec 09, 2011 at 12:47:10PM -0500,
Re: evdev input module and multiple X screen support
Thank you... I will take a look at the new info Regards Curtis Rubel Sent from my iPhone On Dec 9, 2011, at 23:37, Peter Hutterer peter.hutte...@who-t.net wrote: On Fri, Dec 09, 2011 at 12:47:10PM -0500, Curtis Rubel wrote: Hello xorg... Can someone tell me if multiple X screen support is planned for the evdev input module? We have a number of multiple X screen systems here running Xorg using the older evtouch input library and from what I can see it appears this module is no longer supported and being replaced by the evdev module. Is this the case or has the evtouch input library just not been updated yet?? Any help in this matter would be greatly appreciated...as the touch screen vendor ELO does not support multiple USB touchscreens on a single system... input drivers don't do multi-screen handling (anymore), it's all handled by the server now. See the documentation here: http://wiki.x.org/wiki/XInputCoordinateTransformationMatrixUsage 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: Good afternoon
hi Samuel, i have never heard about virtual gl and it seems that this is more a problem of VirtualGL. i used google to found the mail below may be it can help you. http://www.mail-archive.com/virtualgl-users@lists.sourceforge.net/msg00023.html re, wh Am 09.12.2011 08:48, schrieb Samuel Boateng: Hello, I just installed VirtualGL-2.2.90 on my machine which runs on Centos5.7. After installation I had to test to see if everything was successful but unfortunately I encountered this error: Xlib: Extension GLX missing on display 0:0, Error: Couldn't get an RGB Double Buffered visual. I have not found a way out as at now. Could your team please give me some support? Urgently needed. ___ 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
[ANNOUNCE] xorg-server 1.11.2.902 (1.11.3 RC2)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 == Description == This is the second release candidate for xorg-server 1.11.3 and contains fixes for various crashes and correctness issues fixed since the previous release. == Known Issues == Important issues are listed in the 1.11 tracker bug: https://bugs.freedesktop.org/show_bug.cgi?id=xserver-1.11 * #17013: Issues when mising Xinerama and XCopyArea/Xdamage * Partial patch is available... still waiting on complete fix * #29251: [from 1.8.x] server crash destroying GLX pixmaps * #39580: [from 1.9.x] crash in GLX when resizing a window * #39949: [from 1.9.x] RandR panning scaling don't work * #41124: [from 1.9.x] Another crash in GLX/DRI2 when resizing a window Soime additional known issues from the 1.12 tracker would be considered for 1.11 if a fix becomes available: https://bugs.freedesktop.org/show_bug.cgi?id=xserver-1.12 * #11053: Buffer overflow in fbCopyArea() * Has a patch, ajax thinks the patch is wrong * #23938: [from 1.6.x] keys occasionally get stuck * #24094: CTRL-ALT-F1 doesn't switch to VT1 (provides garbage input to terminal instead) * XKB weirdness. This looks diagnosed, so let's get a patch tested. * #27428: xrandr events delayed until a key is pressed * #27804: Enter/Leave event woes with multiple master devices * #31501: [from 1.8.x] crash accessing font info with xfs in fontpath * #32765: [from 1.8.x] Xephyr segfaults on 24bpp hosts * A possible fix is discussed, but Keith didn't like it. * #39094: WaitFor does not handle EIO (causes 100% cpu load) == New Issues == If you encounter an issue that you think should block a future 1.11 release, please follow the instructions listed in the wiki to raise this to our attention. http://www.x.org/wiki/Server111Branch == Changes since 1.11.3 RC1 == Adam Jackson (1): fbdevhw: iterate over all modes that match a mode. (v3) Alan Coopersmith (2): Limit the number of screens Xvfb will attempt to allocate memory for LoaderOpen returns either a valid pointer or NULL, so don't check for 0 Dave Airlie (6): xext: don't free uninitialised pointer when malloc fails. (v2) Xi: avoid overrun of callback array. xaa: avoid possible freed pointer reuse in epilogue xv: test correct number of requests. (v2) hal: free tmp_val in one missing case kdrive: drop screen crossing code. Jeremy Huddleston (1): configure.ac: 1.11.2.902 (1.11.3 RC2) Rui Matos (1): randr: Make the RRConstrainCursorHarder logic the same as miPointerSetPosition git tag: xorg-server-1.11.2.902 http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.11.2.902.tar.bz2 MD5: 010fbad269075ebfc0bb6c6061645f3a xorg-server-1.11.2.902.tar.bz2 SHA1: 8fc112279e15a162bea352ad62fc41a7d8450f2a xorg-server-1.11.2.902.tar.bz2 SHA256: 94120324561b1aad76ac158197c856dfca75f61ea1fe9188533c178ef3214611 xorg-server-1.11.2.902.tar.bz2 http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.11.2.902.tar.gz MD5: 0f86a16d4e1e899170a087d51cee4df1 xorg-server-1.11.2.902.tar.gz SHA1: bbb7864a59189d77c749e4c598820264749ec1ed xorg-server-1.11.2.902.tar.gz SHA256: 5a14200b6cd5506ee218506ac05fbe451039eaccab044033acccf38d286b6bd4 xorg-server-1.11.2.902.tar.gz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) iD8DBQFO4ntDjC1Anjf1NmMRAm4cAJ9zL6Q9n5Z9ulgz+HdATWLhyR4ALQCfffwj lCpeAcIiDHHSBnYuXHwjkaE= =Y+yx -END PGP SIGNATURE- ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
evdev input module and multiple X screen support
Hello xorg... Can someone tell me if multiple X screen support is planned for the evdev input module? We have a number of multiple X screen systems here running Xorg using the older evtouch input library and from what I can see it appears this module is no longer supported and being replaced by the evdev module. Is this the case or has the evtouch input library just not been updated yet?? Any help in this matter would be greatly appreciated...as the touch screen vendor ELO does not support multiple USB touchscreens on a single system... Best Regards, Curtis -- Curtis Rubel Senior Development Engineer Compro Computer Services, Inc. 105 East Drive - Melbourne, Florida, 32904 Phone: 321-727-2211 email: cru...@compro.net Web: http://www.compro.net An ISO 9001:2008 Registered Company --- CONFIDENTIALITY NOTICE: This email transmission, and any documents, files or previous email messages attached to it may contain confidential information that is legally privileged. If you are not the intended recipient or a person responsible for delivering it to the intended recipient, you are hereby notified that any disclosure, copying, distribution, or use of any of the information contained in or attached to this transmission is STRICTLY PROHIBITED. If you have received this transmission in error, please immediately notify the sender by email or call 321-727-2211. Please destroy the original transmission and its attachments without reading or saving it in any manner. ___ 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
[ANNOUNCE] xorg-server 1.11.2.902 (1.11.3 RC2)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 == Description == This is the second release candidate for xorg-server 1.11.3 and contains fixes for various crashes and correctness issues fixed since the previous release. == Known Issues == Important issues are listed in the 1.11 tracker bug: https://bugs.freedesktop.org/show_bug.cgi?id=xserver-1.11 * #17013: Issues when mising Xinerama and XCopyArea/Xdamage * Partial patch is available... still waiting on complete fix * #29251: [from 1.8.x] server crash destroying GLX pixmaps * #39580: [from 1.9.x] crash in GLX when resizing a window * #39949: [from 1.9.x] RandR panning scaling don't work * #41124: [from 1.9.x] Another crash in GLX/DRI2 when resizing a window Soime additional known issues from the 1.12 tracker would be considered for 1.11 if a fix becomes available: https://bugs.freedesktop.org/show_bug.cgi?id=xserver-1.12 * #11053: Buffer overflow in fbCopyArea() * Has a patch, ajax thinks the patch is wrong * #23938: [from 1.6.x] keys occasionally get stuck * #24094: CTRL-ALT-F1 doesn't switch to VT1 (provides garbage input to terminal instead) * XKB weirdness. This looks diagnosed, so let's get a patch tested. * #27428: xrandr events delayed until a key is pressed * #27804: Enter/Leave event woes with multiple master devices * #31501: [from 1.8.x] crash accessing font info with xfs in fontpath * #32765: [from 1.8.x] Xephyr segfaults on 24bpp hosts * A possible fix is discussed, but Keith didn't like it. * #39094: WaitFor does not handle EIO (causes 100% cpu load) == New Issues == If you encounter an issue that you think should block a future 1.11 release, please follow the instructions listed in the wiki to raise this to our attention. http://www.x.org/wiki/Server111Branch == Changes since 1.11.3 RC1 == Adam Jackson (1): fbdevhw: iterate over all modes that match a mode. (v3) Alan Coopersmith (2): Limit the number of screens Xvfb will attempt to allocate memory for LoaderOpen returns either a valid pointer or NULL, so don't check for 0 Dave Airlie (6): xext: don't free uninitialised pointer when malloc fails. (v2) Xi: avoid overrun of callback array. xaa: avoid possible freed pointer reuse in epilogue xv: test correct number of requests. (v2) hal: free tmp_val in one missing case kdrive: drop screen crossing code. Jeremy Huddleston (1): configure.ac: 1.11.2.902 (1.11.3 RC2) Rui Matos (1): randr: Make the RRConstrainCursorHarder logic the same as miPointerSetPosition git tag: xorg-server-1.11.2.902 http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.11.2.902.tar.bz2 MD5: 010fbad269075ebfc0bb6c6061645f3a xorg-server-1.11.2.902.tar.bz2 SHA1: 8fc112279e15a162bea352ad62fc41a7d8450f2a xorg-server-1.11.2.902.tar.bz2 SHA256: 94120324561b1aad76ac158197c856dfca75f61ea1fe9188533c178ef3214611 xorg-server-1.11.2.902.tar.bz2 http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.11.2.902.tar.gz MD5: 0f86a16d4e1e899170a087d51cee4df1 xorg-server-1.11.2.902.tar.gz SHA1: bbb7864a59189d77c749e4c598820264749ec1ed xorg-server-1.11.2.902.tar.gz SHA256: 5a14200b6cd5506ee218506ac05fbe451039eaccab044033acccf38d286b6bd4 xorg-server-1.11.2.902.tar.gz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) iD8DBQFO4ntDjC1Anjf1NmMRAm4cAJ9zL6Q9n5Z9ulgz+HdATWLhyR4ALQCfffwj lCpeAcIiDHHSBnYuXHwjkaE= =Y+yx -END PGP SIGNATURE- ___ 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: evdev input module and multiple X screen support
On Fri, Dec 09, 2011 at 12:47:10PM -0500, Curtis Rubel wrote: Hello xorg... Can someone tell me if multiple X screen support is planned for the evdev input module? We have a number of multiple X screen systems here running Xorg using the older evtouch input library and from what I can see it appears this module is no longer supported and being replaced by the evdev module. Is this the case or has the evtouch input library just not been updated yet?? Any help in this matter would be greatly appreciated...as the touch screen vendor ELO does not support multiple USB touchscreens on a single system... input drivers don't do multi-screen handling (anymore), it's all handled by the server now. See the documentation here: http://wiki.x.org/wiki/XInputCoordinateTransformationMatrixUsage 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
Good afternoon
Hello, I just installed VirtualGL-2.2.90 on my machine which runs on Centos5.7. After installation I had to test to see if everything was successful but unfortunately I encountered this error: Xlib: Extension GLX missing on display 0:0, Error: Couldn't get an RGB Double Buffered visual. I have not found a way out as at now. Could your team please give me some support? Urgently needed. Thank you Samuel ___ 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
[ANNOUNCE] util-macros 1.16.0
Alan Coopersmith (4): Add an optional argument to XORG_LD_WRAP Define __wrap_exit in test program source for XORG_LD_WRAP Add XORG_MEMORY_CHECK_FLAGS and require it in XORG_ENABLE_UNIT_TESTS XORG_TESTSET_CFLAG: Try to both compile link with the flags Gaetan Nadon (1): Version bump: 1.16.0 Jeremy Huddleston (7): Fix the test for -Werror=attributes Add XORG_TESTSET_CFLAG which can be used to test what flags the compiler supports Use XORG_TESTSET_CFLAG in XORG_STRICT_OPTION Add XORG_COMPILER_FLAGS to replace XORG_CWARNFLAGS Update XORG_CWARNFLAGS to use XORG_COMPILER_FLAGS Add additional flags to XORG_COMPILER_FLAGS XORG_TESTSET_CFLAG: Add support fot -Werror=unused-command-line-argument git tag: util-macros-1.16.0 http://xorg.freedesktop.org/archive/individual/util/util-macros-1.16.0.tar.bz2 MD5: f7e1b5fe844da90ab87a0ff989fc09f8 util-macros-1.16.0.tar.bz2 SHA1: 1c08e52ec492df85be49a3b157ec39f7d4e52fa4 util-macros-1.16.0.tar.bz2 SHA256: 931a66d77a6e5a69bf41c5e5fcced83211e8889cd73bc66184b838ae8bd7604b util-macros-1.16.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/util/util-macros-1.16.0.tar.gz MD5: 3f77f0b6452c677d4b5ce9feaea7d15e util-macros-1.16.0.tar.gz SHA1: 2a24ce5008e2d3aa09278d61bc732006b6483469 util-macros-1.16.0.tar.gz SHA256: 1387cec5c2e655811e9a60afee7bda1652f8cd97be6c89418566bcf934ff6935 util-macros-1.16.0.tar.gz signature.asc Description: This is a digitally signed message part ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
Re: rRadeon 9000 + X.Org 1.11.2 + EnablePageFlip + opengl = crash
On Die, 2011-12-06 at 17:44 -0500, Alex Deucher wrote: On Tue, Dec 6, 2011 at 5:04 PM, Giuliano Pochini poch...@shiny.it wrote: I also tried KMS. When EnablePageFlip is enabled glxgears renders nothing and X freezes immediately except the mouse pointer. After a few second the screen blanks and a reboot is the only cure. W/o EnablePageFlip it works better. glxgears looks OK, but it runs at 60fps. xterm colours are wrong. Wrong xterm colours would be an xf86-video-ati issue. Everything else seems fine. Running other 3D apps (Nexuiz, Scorched3D) works fine at first, but seconds or minutes later it locks up the same way without any symptom before that moment. With KMS apps are synced the refresh rate by default, you can override that by setting the env var vblank_mode=0, e.g., vblank_mode=0 glxgears Pageflipping with KMS works fine here, so it may be something mac specific. It works fine on this PowerBook with an RV350, but glxgears can't really use page flipping anyway with KMS, unless you run it in fullscreen mode maybe. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ 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
[ANNOUNCE] util-macros 1.16.0
Alan Coopersmith (4): Add an optional argument to XORG_LD_WRAP Define __wrap_exit in test program source for XORG_LD_WRAP Add XORG_MEMORY_CHECK_FLAGS and require it in XORG_ENABLE_UNIT_TESTS XORG_TESTSET_CFLAG: Try to both compile link with the flags Gaetan Nadon (1): Version bump: 1.16.0 Jeremy Huddleston (7): Fix the test for -Werror=attributes Add XORG_TESTSET_CFLAG which can be used to test what flags the compiler supports Use XORG_TESTSET_CFLAG in XORG_STRICT_OPTION Add XORG_COMPILER_FLAGS to replace XORG_CWARNFLAGS Update XORG_CWARNFLAGS to use XORG_COMPILER_FLAGS Add additional flags to XORG_COMPILER_FLAGS XORG_TESTSET_CFLAG: Add support fot -Werror=unused-command-line-argument git tag: util-macros-1.16.0 http://xorg.freedesktop.org/archive/individual/util/util-macros-1.16.0.tar.bz2 MD5: f7e1b5fe844da90ab87a0ff989fc09f8 util-macros-1.16.0.tar.bz2 SHA1: 1c08e52ec492df85be49a3b157ec39f7d4e52fa4 util-macros-1.16.0.tar.bz2 SHA256: 931a66d77a6e5a69bf41c5e5fcced83211e8889cd73bc66184b838ae8bd7604b util-macros-1.16.0.tar.bz2 http://xorg.freedesktop.org/archive/individual/util/util-macros-1.16.0.tar.gz MD5: 3f77f0b6452c677d4b5ce9feaea7d15e util-macros-1.16.0.tar.gz SHA1: 2a24ce5008e2d3aa09278d61bc732006b6483469 util-macros-1.16.0.tar.gz SHA256: 1387cec5c2e655811e9a60afee7bda1652f8cd97be6c89418566bcf934ff6935 util-macros-1.16.0.tar.gz signature.asc Description: This is a digitally signed message part ___ 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: Question about pixman,x11perf and xserver
On 12/5/11 6:39 AM, 杨帅 wrote: 1.I recompile the pixman with enable-neon,but when I use the x11perf for testing ,I can‘t see the significant difference between the pixman with neon and pixman without neon.That's why? Presumably because you're not hitting a neon-accelerated path. You've not said which x11perf tests you are measuring with. Be aware that many of them are not at all relevant for real world performance. 2.xserver use which drawing library to resizing the window,scroll the text window ,and so on? 3.which library excepts pixman could I optimize using neon to improve the performance of xserver? The X server has an internal library called 'fb' for this. fb is a layer around pixman that implements X core rendering, either by calling down to pixman or directly. - ajax ___ 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: rRadeon 9000 + X.Org 1.11.2 + EnablePageFlip + opengl = crash
On Tue, 6 Dec 2011 08:46:41 + Dave Airlie airl...@gmail.com wrote: On Mon, Dec 5, 2011 at 8:41 PM, Giuliano Pochini poch...@shiny.it wrote: First, my config: :00:10.0 VGA compatible controller: ATI Technologies Inc Radeon RV250 If [Radeon 9000] (rev 01) Linux Jay 3.1.0 #3 SMP Tue Nov 1 17:58:39 CET 2011 ppc 7455, altivec supported PowerMac3,6 GNU/Linux When EnablePageFlip is enabled the machine crashes as soon as another window hides any part of the glxgears window. The screen turns off and a hard reset is needed (Rsys+B does not work). I'm not using KMS. Thats probably the problem then. Supporting UMS is not on anyones list that cares anymore. Well, I think EnablePageFlip was just ignored in older versions of Xorg or kernel. Now, when EnablePageFlip is enabled, glxgears runs about 15% faster, while it made no difference before. I also tried KMS. When EnablePageFlip is enabled glxgears renders nothing and X freezes immediately except the mouse pointer. After a few second the screen blanks and a reboot is the only cure. W/o EnablePageFlip it works better. glxgears looks OK, but it runs at 60fps. xterm colours are wrong. Everything else seems fine. Running other 3D apps (Nexuiz, Scorched3D) works fine at first, but seconds or minutes later it locks up the same way without any symptom before that moment. So unless its a regression in the kernel and you can bisect it I'm not sure you'll see much help. Plus I have pretty old hardware and hard lock ups are hard to debug... -- Giuliano. ___ 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
Question about pixman,x11perf and xserver
hi,all I'am using ubuntu running on our chip of cortex-a9 with neon.And there is no 2D/3D hardware in our chip.There are several questions during my trying to improve the user experience. 1.I recompile the pixman with enable-neon,but when I use the x11perf for testing ,I can‘t see the significant difference between the pixman with neon and pixman without neon.That's why? 2.xserver use which drawing library to resizing the window,scroll the text window ,and so on? 3.which library excepts pixman could I optimize using neon to improve the performance of xserver? Best Regards, David ___ 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: 8k resolution video causes X Error
On 05/12/2011 2:03 AM, Maarten Maathuis wrote: On Sun, Dec 4, 2011 at 6:11 PM, Donald McLachlan donald.mclach...@crc.ca wrote: Hi, I don't know where to start to resolve this problem and guessed maybe this is a good place to start. If not, please point me in the right direction. Our ultimate goal is to stream 8k resolution video using sage (see www.sagecommons.org). - We first used ffmpeg to convert a 4k resolution video file to yuv format, and we were able to view it with ffplay, mplayer, and crcview (an in house program). - We then used ffmpeg to convert/resample the same 4k resolution video file to yuv/8k resolution; the conversion completed without error. - When trying to view the resulting yuv/8k resolution file all three viewer programs failed with the same X Error. For example, here is the output from ffplay: ffplay -i Lupe.8k.yuv -s 8192x4320 -pix_fmt yuv420p -x 1920 -y 1080 ffplay version 0.8, Copyright (c) 2003-2011 the FFmpeg developers built on Nov 30 2011 13:01:22 with gcc 4.5.1 20101208 [gcc-4_5-branch revision 167585] configuration: libavutil51. 9. 1 / 51. 9. 1 libavcodec 53. 7. 0 / 53. 7. 0 libavformat 53. 4. 0 / 53. 4. 0 libavdevice 53. 1. 1 / 53. 1. 1 libavfilter 2. 23. 0 / 2. 23. 0 libswscale2. 0. 0 / 2. 0. 0 [rawvideo @ 0x129d740] Estimating duration from bitrate, this may be inaccurate Input #0, rawvideo, from 'Lupe.8k.yuv': Duration: N/A, start: 0.00, bitrate: N/A Stream #0.0: Video: rawvideo, yuv420p, 8192x4320, 25 tbr, 25 tbn, 25 tbc X Error of failed request: BadLength (poly request too large or internal Xlib length error) Major opcode of failed request: 132 (XVideo) Minor opcode of failed request: 18 () Serial number of failed request: 23 Current serial number in output stream: 24 In case it matters, we are using openSuse 11.4 64 bit linux, on an ASUS P6T7 WS Supercomputer motherboard, with 12 G RAM, and a ASUS GTX590 video card. My guess is the 8k resolution video format is exceeding a buffer size limit somewhere, either in software, or maybe on the video card. Is there a way to find out what buffers are affected and is there a way to overcome these limits? Thanks for any assistance you can provide, Don ___ 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: If this is using the nouveau driver (check lsmod or xorg log), i see that for some reason that it's limited to 4096x4096 for xvideo. See this line: http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/tree/src/nouveau_xv.c#n2031 And then check the contents of DummyEncodingTex and you'll find it refers to the maximum sizes. The command xvinfo confirms this. NV50 and higher (everything starting geforce 8) are able to do 8192x8192, it should just be a matter of making a NV50 specific DummyEncodingTex structure. Hi Maaten, I believe we replaced the nouveau driver with the nvidia driver, but I will double check. I will run the xvinfo command to see what it says limits are. - If need be I guess we could revert to the nouveau driver and modify the DummyEncodingTex structure. - Does anyone know if there something similar we can do with the nvidia driver to enable 8k? (I guess maybe Nvidia are the ones to ask. :-) ) Thanks, and I'll let you know how it goes, Don ___ 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: 8k resolution video causes X Error
On 05/12/2011 9:38 AM, Donald McLachlan wrote: On 05/12/2011 2:03 AM, Maarten Maathuis wrote: On Sun, Dec 4, 2011 at 6:11 PM, Donald McLachlan donald.mclach...@crc.ca wrote: Hi, I don't know where to start to resolve this problem and guessed maybe this is a good place to start. If not, please point me in the right direction. Our ultimate goal is to stream 8k resolution video using sage (see www.sagecommons.org). - We first used ffmpeg to convert a 4k resolution video file to yuv format, and we were able to view it with ffplay, mplayer, and crcview (an in house program). - We then used ffmpeg to convert/resample the same 4k resolution video file to yuv/8k resolution; the conversion completed without error. - When trying to view the resulting yuv/8k resolution file all three viewer programs failed with the same X Error. For example, here is the output from ffplay: ffplay -i Lupe.8k.yuv -s 8192x4320 -pix_fmt yuv420p -x 1920 -y 1080 ffplay version 0.8, Copyright (c) 2003-2011 the FFmpeg developers built on Nov 30 2011 13:01:22 with gcc 4.5.1 20101208 [gcc-4_5-branch revision 167585] configuration: libavutil51. 9. 1 / 51. 9. 1 libavcodec 53. 7. 0 / 53. 7. 0 libavformat 53. 4. 0 / 53. 4. 0 libavdevice 53. 1. 1 / 53. 1. 1 libavfilter 2. 23. 0 / 2. 23. 0 libswscale2. 0. 0 / 2. 0. 0 [rawvideo @ 0x129d740] Estimating duration from bitrate, this may be inaccurate Input #0, rawvideo, from 'Lupe.8k.yuv': Duration: N/A, start: 0.00, bitrate: N/A Stream #0.0: Video: rawvideo, yuv420p, 8192x4320, 25 tbr, 25 tbn, 25 tbc X Error of failed request: BadLength (poly request too large or internal Xlib length error) Major opcode of failed request: 132 (XVideo) Minor opcode of failed request: 18 () Serial number of failed request: 23 Current serial number in output stream: 24 In case it matters, we are using openSuse 11.4 64 bit linux, on an ASUS P6T7 WS Supercomputer motherboard, with 12 G RAM, and a ASUS GTX590 video card. My guess is the 8k resolution video format is exceeding a buffer size limit somewhere, either in software, or maybe on the video card. Is there a way to find out what buffers are affected and is there a way to overcome these limits? Thanks for any assistance you can provide, Don ___ 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: If this is using the nouveau driver (check lsmod or xorg log), i see that for some reason that it's limited to 4096x4096 for xvideo. See this line: http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/tree/src/nouveau_xv.c#n2031 And then check the contents of DummyEncodingTex and you'll find it refers to the maximum sizes. The command xvinfo confirms this. NV50 and higher (everything starting geforce 8) are able to do 8192x8192, it should just be a matter of making a NV50 specific DummyEncodingTex structure. Hi Maaten, I believe we replaced the nouveau driver with the nvidia driver, but I will double check. I will run the xvinfo command to see what it says limits are. - If need be I guess we could revert to the nouveau driver and modify the DummyEncodingTex structure. - Does anyone know if there something similar we can do with the nvidia driver to enable 8k? (I guess maybe Nvidia are the ones to ask. :-) ) Thanks, and I'll let you know how it goes, Don Hi Maarten, (sorry for the typo on your name last time.) lsmod shows: nvidia 11909611 44 and Xorg.0.log shows: /usr/lib64/xorg/modules/drivers/nvidia_drv.so [ 180.902] (II) Module nvidia: vendor=NVIDIA Corporation [ 180.902] compiled for 4.0.2, module version = 1.0.0 [ 180.902] Module class: X.Org Video Driver [ 180.902] (II) NVIDIA dlloader X Driver 285.05.09 Fri Sep 23 17:33:35 PDT 2011 [ 180.902] (II) NVIDIA Unified Driver for all Supported NVIDIA GPUs So I take it we are running the nvidia driver, not the nouveau driver. Also, xvinfo shows maximum XvImage size: 16384 x 16384 Does that cover video, or just static images? In case it helps, I've attached a file with the text output of the 3 commands. Thanks, Don Script started on Mon 05 Dec 2011 10:00:57 AM EST ]2;crc@crc-fsmanager:~]1;crc-fsmanagercrc@crc-fsmanager:~ lsmod ; xvinfo ; cat /var/log/Xorg.0.log Module Size Used by nls_iso8859_1 4633 0 nls_cp437 6319 0 vfat 10387 0 fat52270 1 vfat iptable_filter 1722 0 ip_tables 18968 1 iptable_filter ip6table_filter 1695 0 ip6_tables 19130 1 ip6table_filter x_tables 24840 4 iptable_filter,ip_tables,ip6table_filter,ip6_tables fuse 69275 3 mpt2sas 129590 2
Re: Question about pixman,x11perf and xserver
On 2011-12-05 06:39, 杨帅 wrote: 1.I recompile the pixman with enable-neon,but when I use the x11perf for testing ,I can‘t see the significant difference between the pixman with neon and pixman without neon.That's why? x11perf is an older test suite, and mostly only tests core graphics. Only x11perf -compwinwin and -comppixwin will make heavy use of pixman (along with the new-style text tests, a*text, aa*text and rgb*text to some extent). The good news is, most modern applications draw using those requests. 2.xserver use which drawing library to resizing the window,scroll the text window ,and so on? Depends on the application. Either pixman, or the fb directory of the server. 3.which library excepts pixman could I optimize using neon to improve the performance of xserver? xserver/fb But first, make sure you're working on something that matters to your application. In particular, cairo-perf-trace is probably more relevant these days than x11perf. See http://cgit.freedesktop.org/cairo-traces/tree/README Peter Harris -- Open Text Connectivity Solutions Group Peter Harrishttp://connectivity.opentext.com/ Research and DevelopmentPhone: +1 905 762 6001 phar...@opentext.comToll Free: 1 877 359 4866 ___ 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: 8k resolution video causes X Error
/usr/lib64/xorg/modules/drivers/nvidia_drv.so [ 180.902] (II) Module nvidia: vendor=NVIDIA Corporation [ 180.902] compiled for 4.0.2, module version = 1.0.0 [ 180.902] Module class: X.Org Video Driver [ 180.902] (II) NVIDIA dlloader X Driver 285.05.09 Fri Sep 23 17:33:35 PDT 2011 [ 180.902] (II) NVIDIA Unified Driver for all Supported NVIDIA GPUs So I take it we are running the nvidia driver, not the nouveau driver. You are - so you need to discuss that case with Nvidia not Xorg if you want to make much progress on that driver. Alan ___ 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
rRadeon 9000 + X.Org 1.11.2 + EnablePageFlip + opengl = crash
First, my config: :00:10.0 VGA compatible controller: ATI Technologies Inc Radeon RV250 If [Radeon 9000] (rev 01) Linux Jay 3.1.0 #3 SMP Tue Nov 1 17:58:39 CET 2011 ppc 7455, altivec supported PowerMac3,6 GNU/Linux When EnablePageFlip is enabled the machine crashes as soon as another window hides any part of the glxgears window. The screen turns off and a hard reset is needed (Rsys+B does not work). I'm not using KMS. $ xdpyinfo name of display::0 version number:11.0 vendor string:The X.Org Foundation vendor release number:11102000 X.Org version: 1.11.2 maximum request size: 16777212 bytes motion buffer size: 256 bitmap unit, bit order, padding:32, MSBFirst, 32 image byte order:MSBFirst number of supported pixmap formats:7 supported pixmap formats: depth 1, bits_per_pixel 1, scanline_pad 32 depth 4, bits_per_pixel 8, scanline_pad 32 depth 8, bits_per_pixel 8, scanline_pad 32 depth 15, bits_per_pixel 16, scanline_pad 32 depth 16, bits_per_pixel 16, scanline_pad 32 depth 24, bits_per_pixel 32, scanline_pad 32 depth 32, bits_per_pixel 32, scanline_pad 32 keycode range:minimum 8, maximum 255 focus: window 0xe2, revert to None number of extensions:28 BIG-REQUESTS Composite DAMAGE DOUBLE-BUFFER DPMS DRI2 GLX Generic Event Extension MIT-SCREEN-SAVER MIT-SHM RANDR RECORD RENDER SGI-GLX SHAPE SYNC X-Resource XC-MISC XFIXES XFree86-DGA XFree86-DRI XFree86-VidModeExtension XINERAMA XInputExtension XKEYBOARD XTEST XVideo XVideo-MotionCompensation default screen number:0 number of screens:1 screen #0: print screen:no dimensions:1280x1024 pixels (338x270 millimeters) resolution:96x96 dots per inch depths (7):24, 1, 4, 8, 15, 16, 32 root window id:0x76 depth of root window:24 planes number of colormaps:minimum 1, maximum 1 default colormap:0x20 default number of colormap cells:256 preallocated pixels:black 0, white 16777215 options:backing-store NO, save-unders NO largest cursor:64x64 current input event mask:0xfa200c ButtonPressMask ButtonReleaseMaskButtonMotionMask StructureNotifyMask SubstructureNotifyMask SubstructureRedirectMask FocusChangeMask PropertyChangeMask ColormapChangeMask number of visuals:8 default visual id: 0x21 visual: visual id:0x21 class:TrueColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0x22 class:DirectColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0x70 class:TrueColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0x71 class:TrueColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0x72 class:DirectColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0x73 class:DirectColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0x74 class:DirectColor depth:24 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits visual: visual id:0x67 class:TrueColor depth:32 planes available colormap entries:256 per subfield red, green, blue masks:0xff, 0xff00, 0xff significant bits in color specification:8 bits -- Giuliano. ___ 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:Re: Question about pixman,x11perf and xserver
hi,Peter Thanks for your reply~ Now I got the direction! I will try to optimize the xserver/fb and use the cairo-perf-trace for testing Best Regards, David 在 2011-12-05 23:47:57，Peter Harris phar...@opentext.com 写道： On 2011-12-05 06:39, 杨帅 wrote: 1.I recompile the pixman with enable-neon,but when I use the x11perf for testing ,I can‘t see the significant difference between the pixman with neon and pixman without neon.That's why? x11perf is an older test suite, and mostly only tests core graphics. Only x11perf -compwinwin and -comppixwin will make heavy use of pixman (along with the new-style text tests, a*text, aa*text and rgb*text to some extent). The good news is, most modern applications draw using those requests. 2.xserver use which drawing library to resizing the window,scroll the text window ,and so on? Depends on the application. Either pixman, or the fb directory of the server. 3.which library excepts pixman could I optimize using neon to improve the performance of xserver? xserver/fb But first, make sure you're working on something that matters to your application. In particular, cairo-perf-trace is probably more relevant these days than x11perf. See http://cgit.freedesktop.org/cairo-traces/tree/README Peter Harris -- Open Text Connectivity Solutions Group Peter Harrishttp://connectivity.opentext.com/ Research and DevelopmentPhone: +1 905 762 6001 phar...@opentext.comToll Free: 1 877 359 4866 ___ 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: yangshuai...@126.com ___ 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
8k resolution video causes X Error
Hi, I don't know where to start to resolve this problem and guessed maybe this is a good place to start. If not, please point me in the right direction. Our ultimate goal is to stream 8k resolution video using sage (see www.sagecommons.org). - We first used ffmpeg to convert a 4k resolution video file to yuv format, and we were able to view it with ffplay, mplayer, and crcview (an in house program). - We then used ffmpeg to convert/resample the same 4k resolution video file to yuv/8k resolution; the conversion completed without error. - When trying to view the resulting yuv/8k resolution file all three viewer programs failed with the same X Error. For example, here is the output from ffplay: ffplay -i Lupe.8k.yuv -s 8192x4320 -pix_fmt yuv420p -x 1920 -y 1080 ffplay version 0.8, Copyright (c) 2003-2011 the FFmpeg developers built on Nov 30 2011 13:01:22 with gcc 4.5.1 20101208 [gcc-4_5-branch revision 167585] configuration: libavutil51. 9. 1 / 51. 9. 1 libavcodec 53. 7. 0 / 53. 7. 0 libavformat 53. 4. 0 / 53. 4. 0 libavdevice 53. 1. 1 / 53. 1. 1 libavfilter 2. 23. 0 / 2. 23. 0 libswscale2. 0. 0 / 2. 0. 0 [rawvideo @ 0x129d740] Estimating duration from bitrate, this may be inaccurate Input #0, rawvideo, from 'Lupe.8k.yuv': Duration: N/A, start: 0.00, bitrate: N/A Stream #0.0: Video: rawvideo, yuv420p, 8192x4320, 25 tbr, 25 tbn, 25 tbc X Error of failed request: BadLength (poly request too large or internal Xlib length error) Major opcode of failed request: 132 (XVideo) Minor opcode of failed request: 18 () Serial number of failed request: 23 Current serial number in output stream: 24 In case it matters, we are using openSuse 11.4 64 bit linux, on an ASUS P6T7 WS Supercomputer motherboard, with 12 G RAM, and a ASUS GTX590 video card. My guess is the 8k resolution video format is exceeding a buffer size limit somewhere, either in software, or maybe on the video card. Is there a way to find out what buffers are affected and is there a way to overcome these limits? Thanks for any assistance you can provide, Don ___ 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: 8k resolution video causes X Error
On Sun, Dec 4, 2011 at 6:11 PM, Donald McLachlan donald.mclach...@crc.ca wrote: Hi, I don't know where to start to resolve this problem and guessed maybe this is a good place to start. If not, please point me in the right direction. Our ultimate goal is to stream 8k resolution video using sage (see www.sagecommons.org). - We first used ffmpeg to convert a 4k resolution video file to yuv format, and we were able to view it with ffplay, mplayer, and crcview (an in house program). - We then used ffmpeg to convert/resample the same 4k resolution video file to yuv/8k resolution; the conversion completed without error. - When trying to view the resulting yuv/8k resolution file all three viewer programs failed with the same X Error. For example, here is the output from ffplay: ffplay -i Lupe.8k.yuv -s 8192x4320 -pix_fmt yuv420p -x 1920 -y 1080 ffplay version 0.8, Copyright (c) 2003-2011 the FFmpeg developers built on Nov 30 2011 13:01:22 with gcc 4.5.1 20101208 [gcc-4_5-branch revision 167585] configuration: libavutil 51. 9. 1 / 51. 9. 1 libavcodec 53. 7. 0 / 53. 7. 0 libavformat 53. 4. 0 / 53. 4. 0 libavdevice 53. 1. 1 / 53. 1. 1 libavfilter 2. 23. 0 / 2. 23. 0 libswscale 2. 0. 0 / 2. 0. 0 [rawvideo @ 0x129d740] Estimating duration from bitrate, this may be inaccurate Input #0, rawvideo, from 'Lupe.8k.yuv': Duration: N/A, start: 0.00, bitrate: N/A Stream #0.0: Video: rawvideo, yuv420p, 8192x4320, 25 tbr, 25 tbn, 25 tbc X Error of failed request: BadLength (poly request too large or internal Xlib length error) Major opcode of failed request: 132 (XVideo) Minor opcode of failed request: 18 () Serial number of failed request: 23 Current serial number in output stream: 24 In case it matters, we are using openSuse 11.4 64 bit linux, on an ASUS P6T7 WS Supercomputer motherboard, with 12 G RAM, and a ASUS GTX590 video card. My guess is the 8k resolution video format is exceeding a buffer size limit somewhere, either in software, or maybe on the video card. Is there a way to find out what buffers are affected and is there a way to overcome these limits? Thanks for any assistance you can provide, Don ___ 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: madman2...@gmail.com If this is using the nouveau driver (check lsmod or xorg log), i see that for some reason that it's limited to 4096x4096 for xvideo. See this line: http://cgit.freedesktop.org/nouveau/xf86-video-nouveau/tree/src/nouveau_xv.c#n2031 And then check the contents of DummyEncodingTex and you'll find it refers to the maximum sizes. The command xvinfo confirms this. NV50 and higher (everything starting geforce 8) are able to do 8192x8192, it should just be a matter of making a NV50 specific DummyEncodingTex structure. -- Far away from the primal instinct, the song seems to fade away, the river get wider between your thoughts and the things we do and say. ___ 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: [Xcb] [admin] X.Org list configuration change
[Dropping the CCs to announce and commit lists.] On Fri, Dec 02, 2011 at 06:19:44PM +, Daniel Stone wrote: Hi all, To clean things up a bit, we will be moving the following lists from lists.freedesktop.org to lists.x.org on Tuesday afternoon European time: xorg@lists.freedesktop.org xorg-annou...@lists.freedesktop.org xorg-com...@lists.freedesktop.org x...@lists.freedesktop.org xcb-comm...@lists.freedesktop.org Will the existing email addresses for those lists continue to work? Some of those list addresses have various references scattered about, and it would help if they forwarded to the new location. - Josh Triplett ___ 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
[admin] X.Org list configuration change
Hi all, To clean things up a bit, we will be moving the following lists from lists.freedesktop.org to lists.x.org on Tuesday afternoon European time: xorg@lists.freedesktop.org xorg-annou...@lists.freedesktop.org xorg-com...@lists.freedesktop.org x...@lists.freedesktop.org xcb-comm...@lists.freedesktop.org If you are currently filtering based on the List-Id header, please note that unfortunately this will change to listname.lists.x.org, so please update your filters, or be ready to cope with a bunch of noise in your inbox. Cheers, Daniel ___ 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: [Xcb] [admin] X.Org list configuration change
Hi, On 2 December 2011 18:34, Josh Triplett j...@joshtriplett.org wrote: On Fri, Dec 02, 2011 at 06:19:44PM +, Daniel Stone wrote: Hi all, To clean things up a bit, we will be moving the following lists from lists.freedesktop.org to lists.x.org on Tuesday afternoon European time: [...] Will the existing email addresses for those lists continue to work? Some of those list addresses have various references scattered about, and it would help if they forwarded to the new location. Sorry, I should've clarified: yes, they will both now and always. Cheers, Daniel ___ 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
Sticky keys auto unlatch timeout
Is there a way to specify a timeout for sticky keys ? EG all modifiers be automatically unlatched after 1 second without keyboard activity ? Expiry turns the feature off completely. I just need to unlatch. Thanks in advance. -- André Majorel http://www.teaser.fr/~amajorel/ ___ 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
Selective stickiness
Is there is a way to say which keys should be sticky ? For some, a sticky [alt] is arguably more dangerous than useful. Especially if there is no timeout. -- André Majorel http://www.teaser.fr/~amajorel/ ___ 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
synaptics driver for my touchpad
Hello list! I bought a Samsung 900X3A-B01SE (also known as a Samsung Series 9 with Intel i5 sold in Sweden) today. It has a Synaptic touchpad, but it doesn't get recognized as a touchpad by the synaptics input driver. I just gets recognized as a regular mouse device. How can I produce some kind of product id for this device, so that I can search for others with similar problems? And if it is just too new to be recognized, in what sources should I try to put a patch so that it gets recognized? (this assumes that the fix is trivial and more a question of detection than anything else) I am attaching my xorg log, and if you need any other information from me just tell me and I will be happy to provide it :D regards, //Martin [ 453.429] X.Org X Server 1.11.1.902 (1.11.2 RC 2) Release Date: 2011-10-28 [ 453.429] X Protocol Version 11, Revision 0 [ 453.429] Build Operating System: Linux 3.1.0-rc4-amd64 x86_64 Debian [ 453.429] Current Operating System: Linux dagon 3.2.0-rc3 #2 SMP Tue Nov 29 21:42:45 CET 2011 x86_64 [ 453.429] Kernel command line: BOOT_IMAGE=/vmlinuz-3.2.0-rc3 root=/dev/mapper/dagon-root ro quiet pcie_aspm=force [ 453.429] Build Date: 02 November 2011 10:15:50AM [ 453.429] xorg-server 2:1.11.1.902-1 (Cyril Brulebois k...@debian.org) [ 453.429] Current version of pixman: 0.24.0 [ 453.429] Before reporting problems, check http://wiki.x.org to make sure that you have the latest version. [ 453.429] Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. [ 453.429] (==) Log file: /var/log/Xorg.0.log, Time: Tue Nov 29 22:54:10 2011 [ 453.429] (==) Using config file: /etc/X11/xorg.conf [ 453.429] (==) Using system config directory /usr/share/X11/xorg.conf.d [ 453.430] (==) ServerLayout Default [ 453.430] (**) |--Screen Screen (0) [ 453.430] (**) | |--Monitor Monitor [ 453.430] (**) | |--Device Card [ 453.430] (**) |--Input Device Touchpad [ 453.430] (**) |--Input Device Keyboard [ 453.430] (==) Automatically adding devices [ 453.430] (==) Automatically enabling devices [ 453.430] (WW) The directory /usr/share/fonts/X11/cyrillic does not exist. [ 453.430] Entry deleted from font path. [ 453.430] (WW) The directory /usr/share/fonts/X11/cyrillic does not exist. [ 453.430] Entry deleted from font path. [ 453.431] (**) FontPath set to: /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType, built-ins, /usr/share/fonts/X11/misc, /usr/share/fonts/X11/100dpi/:unscaled, /usr/share/fonts/X11/75dpi/:unscaled, /usr/share/fonts/X11/Type1, /usr/share/fonts/X11/100dpi, /usr/share/fonts/X11/75dpi, /var/lib/defoma/x-ttcidfont-conf.d/dirs/TrueType, built-ins [ 453.431] (**) ModulePath set to /usr/lib/xorg/modules [ 453.431] (II) The server relies on udev to provide the list of input devices. If no devices become available, reconfigure udev or disable AutoAddDevices. [ 453.431] (WW) Hotplugging is on, devices using drivers 'kbd', 'mouse' or 'vmmouse' will be disabled. [ 453.431] (WW) Disabling Keyboard [ 453.431] (II) Loader magic: 0x7ff267031ae0 [ 453.431] (II) Module ABI versions: [ 453.431] X.Org ANSI C Emulation: 0.4 [ 453.431] X.Org Video Driver: 11.0 [ 453.431] X.Org XInput driver : 13.0 [ 453.431] X.Org Server Extension : 6.0 [ 453.432] (--) PCI:*(0:0:2:0) 8086:0116:144d:c098 rev 9, Mem @ 0xc000/4194304, 0xb000/268435456, I/O @ 0x3000/64 [ 453.432] (II) Open ACPI successful (/var/run/acpid.socket) [ 453.432] (II) extmod will be loaded. This was enabled by default and also specified in the config file. [ 453.432] (II) dbe will be loaded. This was enabled by default and also specified in the config file. [ 453.432] (II) glx will be loaded. This was enabled by default and also specified in the config file. [ 453.432] (II) record will be loaded. This was enabled by default and also specified in the config file. [ 453.432] (II) dri will be loaded. This was enabled by default and also specified in the config file. [ 453.432] (II) dri2 will be loaded. This was enabled by default and also specified in the config file. [ 453.432] (II) LoadModule: record [ 453.433] (II) Loading /usr/lib/xorg/modules/extensions/librecord.so [ 453.433] (II) Module record: vendor=X.Org Foundation [ 453.433] compiled for 1.11.1.902, module version = 1.13.0 [ 453.433] Module class: X.Org Server Extension [ 453.433] ABI class: X.Org Server Extension, version 6.0 [ 453.433] (II) Loading extension RECORD [ 453.433] (II) LoadModule: dri [ 453.433] (II) Loading /usr/lib/xorg/modules/extensions/libdri.so [ 453.433] (II) Module dri: vendor=X.Org Foundation [ 453.433] compiled for
[ANNOUNCE] xorg-server 1.11.2.901 (1.11.3 RC1)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 == Description == This is the first release candidate for xorg-server 1.11.3 and contains fixes for various crashes and correctness issues fixed since the previous release. Sorry for this being a few days late. Blame Thanksgiving ;) == Known Issues == Important issues are listed in the 1.11 tracker bug: https://bugs.freedesktop.org/show_bug.cgi?id=xserver-1.11 * #17013: Issues when mising Xinerama and XCopyArea/Xdamage * Partial patch is available... still waiting on complete fix * #29251: [from 1.8.x] server crash destroying GLX pixmaps * #39580: [from 1.9.x] crash in GLX when resizing a window * #39949: [from 1.9.x] RandR panning scaling don't work * #41124: [from 1.9.x] Another crash in GLX/DRI2 when resizing a window Soime additional known issues from the 1.12 tracker would be considered for 1.11 if a fix becomes available: https://bugs.freedesktop.org/show_bug.cgi?id=xserver-1.12 * #11053: Buffer overflow in fbCopyArea() * Has a patch, ajax thinks the patch is wrong * #23938: [from 1.6.x] keys occasionally get stuck * #24094: CTRL-ALT-F1 doesn't switch to VT1 (provides garbage input to terminal instead) * XKB weirdness. This looks diagnosed, so let's get a patch tested. * #27428: xrandr events delayed until a key is pressed * #27804: Enter/Leave event woes with multiple master devices * #31501: [from 1.8.x] crash accessing font info with xfs in fontpath * #32765: [from 1.8.x] Xephyr segfaults on 24bpp hosts * A possible fix is discussed, but Keith didn't like it. * #39094: WaitFor does not handle EIO (causes 100% cpu load) == New Issues == If you encounter an issue that you think should block a future 1.11 release, please follow the instructions listed in the wiki to raise this to our attention. http://www.x.org/wiki/Server111Branch == Changes since 1.11.2 == Chris Wilson (3): VidMode: prevent crash with no modes DRI2: Avoid a NULL pointer dereference dri2: Register the DRI2DrawableType after server regeneration Christopher Yeleighton (1): Bug 38420: Xvfb crashes in miInitVisuals() when started with depth=2 Dave Airlie (1): xf86Crtc: handle no outputs with no modes harder. Derek Buitenhuis (1): Fix vesa's VBE PanelID interpretation Jeremy Huddleston (3): xfree86: Fix powerpc build with -Werror=int-to-pointer-cast -Werror=pointer-to-int-cast dmx: Build fix for -Werror=implicit-function-declaration configure.ac: 1.11.2.901 (1.11.3 RC1) Peter Hutterer (4): dix: block signals when closing all devices Xi: allow passive keygrabs on the XIAll(Master)Devices fake devices dix: Don't let a driver without a ProximityClassRec post events include: export GetProximityEvents and QueueProximityEvents Rami Ylimäki (1): record: Prevent out of bounds access when recording a reply. Ross Burton (1): edid: Add quirk for Acer Aspire One 110 dtakahashi42 (1): rootless: Fix a server crash when choosing a color with the gimp color wheel git tag: xorg-server-1.11.2.901 http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.11.2.901.tar.bz2 MD5: 5855fd39e50bcbf9f07001a6648be759 xorg-server-1.11.2.901.tar.bz2 SHA1: 5486f5626f8cc4154dd3a0c6f63b13cf0c9f99c4 xorg-server-1.11.2.901.tar.bz2 SHA256: 002a79942d57b6f442539f9b841d4bfcb80e545e2753b7cf55ad4596a8835cb9 xorg-server-1.11.2.901.tar.bz2 http://xorg.freedesktop.org/archive/individual/xserver/xorg-server-1.11.2.901.tar.gz MD5: 34a84a4195c97e19ca7984f9f02547a8 xorg-server-1.11.2.901.tar.gz SHA1: 74d3485624cb7e1edf537d4d3b59e4b1ed93eacd xorg-server-1.11.2.901.tar.gz SHA256: bd40491598c057cdb45917df571fc6da847b4efbb5870d171e194795e2fb9189 xorg-server-1.11.2.901.tar.gz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (Darwin) iD8DBQFO00OOjC1Anjf1NmMRAqipAJ9Q3AXDYsm0oJivp5gu8mpg8JpV9QCfbReH UM1T1n6skSzAlKFc3DVGbFk= =mAug -END PGP SIGNATURE- ___ 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 performance problem
Am 28.11.2011 07:43, schrieb Maarten Maathuis: ___ 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: madman2...@gmail.com No, damage is an extention, it is called by EXA, it's probably adding all you rectangles to a damage region used to determine how much data is actually valid (needed for ram--vram migrations for example). One thing that just comes to mind, if you are rendering a million rectangles, how many of those do you actually see on your screen? Most of them are only 1x1 pixel wide. And lots of rectangles share the same pixel. I assue that one can optimize the application. But I did not write it and do not know how it works. I only know that it was able to show vector pictures consisting of millions of rectangles within seconds (VLSI design data) when run on XFree86. With Xorg it takes minutes. I only see the problem because we recently upgraded our X11 thin clients to better hardware. But they turned out to be much slower than the older ones. My quest to find the problem has led me to the damage extension now. First I thought it was a network problem. But Xorg was also slow on my notebook when the program was started locally. The contrast is striking: The old XFree86 thin clients were able to draw all the rectangles that were sent over a 100 MBit ethernet network in seconds. While my more powerful Xorg server needs minutes although the software runs on the same machine. However, I was able to improve the runtime of the first operation in damagePolyRectangle. The runtime of my benchmark went down from 90 seconds to 64 seconds. Now one has to look at (*pGC-ops-PolyRectangle)(pDrawable, pGC, nRects, pRects); Thanks Christoph ___ 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: Disabling EXA
On Sat, Nov 26, 2011 at 10:33 AM, Christoph Bartoschek bartosc...@or.uni-bonn.de wrote: Hi, how can I disable EXA and use XAA? I am on opensuse and added the following section to /etc/X11/xorg.conf.d/50-device.conf: Section Device Option AccelMethod xaa Identifier Default Device EndSection Xorg reads the file because it says in its logfile: [ 21.481] (==) RADEON(0): Depth 24, (--) framebuffer bpp 32 [ 21.481] (II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps) [ 21.481] (==) RADEON(0): Default visual is TrueColor [ 21.481] (**) RADEON(0): Option AccelMethod xaa [ 21.481] (==) RADEON(0): RGB weight 888 [ 21.481] (II) RADEON(0): Using 8 bits per RGB (8 bit DAC) [ 21.481] (--) RADEON(0): Chipset: ATI Radeon Mobility X300 (M22) 5460 (PCIE) (ChipID = 0x5460) [ 21.481] (II) RADEON(0): PCIE card detected But EXA is still used: [ 21.481] (II) Loading sub module exa [ 21.481] (II) LoadModule: exa [ 21.482] (II) Loading /usr/lib/xorg/modules/libexa.so [ 21.488] (II) Module exa: vendor=X.Org Foundation [ 21.488] compiled for 1.10.4, module version = 2.5.0 ... [ 21.575] (II) RADEON(0): EXA: Driver will allow EXA pixmaps in VRAM ... [ 21.635] (II) RADEON(0): Setting EXA maxPitchBytes [ 21.635] (II) EXA(0): Driver allocated offscreen pixmaps [ 21.635] (II) EXA(0): Driver registered support for the following operations: [ 21.635] (II) Solid [ 21.635] (II) Copy [ 21.635] (II) Composite (RENDER acceleration) [ 21.635] (II) UploadToScreen [ 21.635] (II) DownloadFromScreen How can I disable EXA and use XAA?. I suspect EXA to be responsible for a huge performance regression. XAA is not compatible with KMS. Alex ___ 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: hdmi output not detected by xrandr
On Tue Nov 29 00:00:34 2011, sashan wrote: On Sun Nov 27 18:51:03 2011, sashan wrote: On Sat Nov 26 22:13:49 2011, Keith Packard wrote: On Sun, 27 Nov 2011 16:01:52 +1100, sashan sas...@zenskg.net wrote: Hi I'm trying to figure out why the external hdmi output on my laptop doesn't work but am not sure where the problem is or if this is the right mailing list. I'd bet money that the hdmi connector is only hooked up to the nVidia device, which means you'd have to use that one to display anything over that connector. Yeah that might be the case but the document http://www.nvidia.com/object/LO_optimus_whitepapers.html about nvidia optimus basically says that the datapath to the physical monitor is always through the Intel IGP and then the IGP is responsible for writing to the display. The nVidia chip is between the application and the IGP, therefore I expected that the IGP would be connected to the HDMI port. However I'm probably wrong and would appreciate if you or someone could clarify my understanding about how this is meant to work. The laptop is a Dell XPS 15z (http://reviews.cnet.com/laptops/dell-xps-15z/4507-3121_7-34714594.html) I've been able to get output from the HDMI port onto the monitor by adding the ModulePath to the nvidia driver to xorg.conf, so it looks like you're right about the fact that it's connected to the nVidia gpu. The problem now is that the higher resolutions aren't detected. The highest it goes is 640x480. I've tried to manually add a modeline but this is ignored. The xorg log shows this when it encounteres the modeline it can't validate: (WW) NVIDIA(0): No valid modes for 1920x1080; removing. Is there anyway I can fix this? I've attached the xorg.conf and xorg log file. Never mind I've got this working. ReadEDID was set to false in the xorg.conf I posted. I deleted that and X is able to correctly detect modelines. ___ 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 performance problem
Am 28.11.2011 10:35, schrieb Christoph Bartoschek:
Now one has to look at
(*pGC-ops-PolyRectangle)(pDrawable, pGC, nRects, pRects);
Here is what I see so far:
- damagePolyRectangle is called for 2044 rectangles.
- the damage region is computed it consists of about 1000 rectangles
each time.
- miPolyRectangle is called.
- the function iterates over all rectangles and calls exaPolylines for
each of them because most have only a width and height of 0
- exaPolylines calls ExaCheckPolylines.
We see that for each rectanlge ExaCheckPolylines is called. I have added
timers to this function to see what costs time:
void
ExaCheckPolylines (DrawablePtr pDrawable, GCPtr pGC,
int mode, int npt, DDXPointPtr ppt)
{
EXA_PRE_FALLBACK_GC(pGC);
EXA_FALLBACK((to %p (%c), width %d, mode %d, count %d\n,
pDrawable, exaDrawableLocation(pDrawable),
pGC-lineWidth, mode, npt));
exaPrepareAccess (pDrawable, EXA_PREPARE_DEST); // Step1: 55 s
exaPrepareAccessGC (pGC); // Step2: 2.4 s
pGC-ops-Polylines (pDrawable, pGC, mode, npt, ppt); // Step3: 2.4 s
exaFinishAccessGC (pGC); // Step4: 2.2 s
exaFinishAccess (pDrawable, EXA_PREPARE_DEST);// Step5: 2.2 s
EXA_POST_FALLBACK_GC(pGC);
}
We see that exaPrepareAccess needs most of the time. Is that expected?
Inside we see that there are some region operations on the damage region
in exaCopyDirty. As said before the damage region contains about 1000
rectangles. So we have 2000 times several operations on 1000 rectangeles.
I think this explains the runtime.
Isn't it somehow possible to batch the rectangle drawing such that the
region operations are not neccessary for each rectangle?
Isn't is possible to expand the damage region such that it contains less
rectangles?
Is this still the correct list, or should I ask the EXA questions elsewhere?
Christoph
___
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: [ANNOUNCE] xf86-video-ati 6.14.3
snip * vdpau/XvMC support (currently only available for = R3xx via Gallium3D). /snip How can i test this? Do I need to configure something? Is there a way to check if this works? Hardware: fusion e350 in lenovo x121e ___ 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 performance problem
On Mon, Nov 28, 2011 at 4:49 PM, Christoph Bartoschek
bartosc...@or.uni-bonn.de wrote:
Am 28.11.2011 10:35, schrieb Christoph Bartoschek:
Now one has to look at
(*pGC-ops-PolyRectangle)(pDrawable, pGC, nRects, pRects);
Here is what I see so far:
- damagePolyRectangle is called for 2044 rectangles.
- the damage region is computed it consists of about 1000 rectangles each
time.
- miPolyRectangle is called.
- the function iterates over all rectangles and calls exaPolylines for each
of them because most have only a width and height of 0
- exaPolylines calls ExaCheckPolylines.
We see that for each rectanlge ExaCheckPolylines is called. I have added
timers to this function to see what costs time:
void
ExaCheckPolylines (DrawablePtr pDrawable, GCPtr pGC,
int mode, int npt, DDXPointPtr ppt)
{
EXA_PRE_FALLBACK_GC(pGC);
EXA_FALLBACK((to %p (%c), width %d, mode %d, count %d\n,
pDrawable, exaDrawableLocation(pDrawable),
pGC-lineWidth, mode, npt));
exaPrepareAccess (pDrawable, EXA_PREPARE_DEST); // Step1: 55 s
exaPrepareAccessGC (pGC); // Step2: 2.4 s
pGC-ops-Polylines (pDrawable, pGC, mode, npt, ppt); // Step3: 2.4 s
exaFinishAccessGC (pGC); // Step4: 2.2 s
exaFinishAccess (pDrawable, EXA_PREPARE_DEST); // Step5: 2.2 s
EXA_POST_FALLBACK_GC(pGC);
}
We see that exaPrepareAccess needs most of the time. Is that expected?
Inside we see that there are some region operations on the damage region in
exaCopyDirty. As said before the damage region contains about 1000
rectangles. So we have 2000 times several operations on 1000 rectangeles.
I think this explains the runtime.
Isn't it somehow possible to batch the rectangle drawing such that the
region operations are not neccessary for each rectangle?
Isn't is possible to expand the damage region such that it contains less
rectangles?
Is this still the correct list, or should I ask the EXA questions elsewhere?
Christoph
___
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: madman2...@gmail.com
EXA doesn't have a seperate list, but now that you ask, you should
probably move to the xorg-devel mailinglist :-)
I don't have any answers right now, but i'll think about it.
--
Far away from the primal instinct, the song seems to fade away, the
river get wider between your thoughts and the things we do and say.
___
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: [ANNOUNCE] xorg-server 1.11.99.1
On Sun, Nov 20, 2011 at 03:20:11PM -0800, Keith Packard wrote: We discussed doing regular releases from master, and Jeremy suggested (sensibly) that we just do them whenever there's a stable release. I completely spaced that plan, nor was I looking at the Google X.org calendar. In any case, here's the current state of master. It's missing a pull request from alanc -- there were a couple of build failures in that which I've replied back about and I expect that'll be fixed shortly. For those interested in helping out, here's the 1.12 release tracker. https://bugs.freedesktop.org/show_bug.cgi?id=40982 Anyone interested in helping clean up the release is encouraged to take a look at the outstanding bugs there. There's a slight snag about the 1.12 release schedule. I'm going biking in New Zealand next February, leaving on the 9th and not getting back until March 1st. So, we can either have the release done before I leave, or wait until I get back. It seems like the former might work a bit better, but it would mean pulling the release in to Feb 8th or so. Anyone have an opinion on the matter? We probably won't get X Input 2.2 done if the release is moved forward to Feb 8th. What's the date for the merge window end? Cheers, Peter ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
Re: [ANNOUNCE] xorg-server 1.11.99.1
On Sun, Nov 27, 2011 at 07:29:53PM -0800, Keith Packard wrote: On Mon, 28 Nov 2011 11:39:31 +1000, Peter Hutterer peter.hutte...@who-t.net wrote: We probably won't get X Input 2.2 done if the release is moved forward to Feb 8th. What's the date for the merge window end? If we followed the 1.11 schedule, the non-critical bug window would close three weeks earlier (Jan 18), and the merge window two months before that (Nov 18), which is now nine days past... If you think X Input 2.2 is nearly ready for merging , I'd say we should go for it and get that merged by Christmas, then plan on closing the non-critical bug window in the first week of February and then finish the release in the first week of March. If you don't think X Input 2.2 will be ready by then, we should probably just close out the merge window earlier, and plan on getting the release out the door by the time I go biking. I think Christmas is realistic for the merge. We're quite some way there, but pointer emulation and the resulting grab hilarity is still missing (Chase has worked on this while I was away but I haven't looked at the current state yet) Cheers, Peter ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
Re: [ANNOUNCE] xorg-server 1.11.99.1
On Mon, 28 Nov 2011 13:36:35 +1000, Peter Hutterer peter.hutte...@who-t.net wrote: On Sun, Nov 27, 2011 at 07:29:53PM -0800, Keith Packard wrote: On Mon, 28 Nov 2011 11:39:31 +1000, Peter Hutterer peter.hutte...@who-t.net wrote: We probably won't get X Input 2.2 done if the release is moved forward to Feb 8th. What's the date for the merge window end? If we followed the 1.11 schedule, the non-critical bug window would close three weeks earlier (Jan 18), and the merge window two months before that (Nov 18), which is now nine days past... If you think X Input 2.2 is nearly ready for merging , I'd say we should go for it and get that merged by Christmas, then plan on closing the non-critical bug window in the first week of February and then finish the release in the first week of March. If you don't think X Input 2.2 will be ready by then, we should probably just close out the merge window earlier, and plan on getting the release out the door by the time I go biking. I think Christmas is realistic for the merge. We're quite some way there, but pointer emulation and the resulting grab hilarity is still missing (Chase has worked on this while I was away but I haven't looked at the current state yet) I'd say we should go for it then. I'll plan on checking my inbox for critical patches while I'm on my bike trip, but we haven't had a lot of patches in that window in the past, so I don't expect things to back up much. -- keith.pack...@intel.com pgpdxJNZCUWBM.pgp Description: PGP signature ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
trouble with touch-sensitive mute button on Lenovo Ideapad Z560
Hi all! Sorry for my bad english, I'm from Russia. I have trouble with touch-sensitive mute button on my laptop Lenovo Ideapad Z560-3KB. On console (system start without X Server) button send keycode, but, button backlight not changed. But, when I start X Server, and the volume is turned on - it's active, when the volume is off - it's not active Muted Mode Photo: http://storage1.static.itmages.ru/i/11/0912/h_1315827236_5918988_cb6c13d5e5.jpeg Unmuted Mode Photo: http://storage1.static.itmages.ru/i/11/0912/h_1315827236_5918988_439db3b21a.jpeg Best regards, Alexander. ___ 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
obliging X to start with 1280x1024
Hi, since some time I have the problem with one of my monitors that X most of the time starts with a very low screen-resolution. My way to deal this at the moment is to init 3/5 with switching off/on the screen until X starts with the proper resolution of 1280x1024. The system always boots with 1280x1024, and when I switch to the command line with CTRL-ALT-F1 I always have the 1280x1024 there. I conlcude therefor that it's not a problem of the monitor itself. I've tried to solve this problem on the opensuse-de maillinglist, and I tried different settings, but nothing worked. How can I oblige X to start this monitor with 1280x1024? I'm running openSuSE 11.4 with: rpm -qa | grep X11 xorg-x11-libX11-ccache-7.6-2.3.i586 xorg-x11-libX11-7.6-10.2.i586 xorg-x11-libX11-devel-7.6-10.2.i586 I include my xorg.conf at the end of the mail. Is there any other information you need to help me solving this? Thanks Karl ___ My xorg.conf: ___ # nvidia-settings: X configuration file generated by nvidia-settings # nvidia-settings: version 275.21 (buildmeis...@swio-display-x86-rhel47-03.nvidia.com) Mon Jul 18 14:59:29 PDT 2011 Section ServerLayout Identifier Layout0 Screen 0 Screen0 1200 0 Screen 1 Screen1 LeftOf Screen0 InputDeviceKeyboard0 CoreKeyboard InputDeviceMouse0 CorePointer Option Xinerama 1 EndSection Section Files EndSection Section InputDevice # generated from default Identifier Mouse0 Driver mouse Option Protocol auto Option Device /dev/psaux Option Emulate3Buttons no Option ZAxisMapping 4 5 EndSection Section InputDevice # generated from default Identifier Keyboard0 Driver kbd EndSection Section Monitor # HorizSync source: edid, VertRefresh source: edid Identifier Monitor0 VendorName Unknown ModelName AOC 2436 HorizSync 30.0 - 80.0 VertRefresh 56.0 - 75.0 Option DPMS EndSection Section Monitor # HorizSync source: unknown, VertRefresh source: unknown Identifier Monitor1 VendorName Unknown ModelName CRT-1 HorizSync 30.0 - 80.0 VertRefresh 50.0 - 75.0 Option DPMS Modeline 1280x1024_60.00 109.00 1280 1368 1496 1712 1024 1027 1034 1063 -hsync +vsync Option PreferredMode 1280x1024_60.00 EndSection Section Device Identifier Device0 Driver nvidia VendorName NVIDIA Corporation BoardName GeForce 6800 BusID PCI:1:0:0 Screen 0 EndSection Section Device Identifier Device1 Driver nvidia VendorName NVIDIA Corporation BoardName GeForce 6800 BusID PCI:1:0:0 Screen 1 EndSection Section Screen Identifier Screen0 Device Device0 MonitorMonitor0 DefaultDepth24 Option TwinView 0 Option TwinViewXineramaInfoOrder CRT-0 Option metamodes CRT-0: nvidia-auto-select +0+0 SubSection Display Depth 24 EndSubSection EndSection Section Screen # Removed Option metamodes CRT-1: 1200x1024 +0+0 Identifier Screen1 Device Device1 MonitorMonitor1 DefaultDepth24 Option TwinView 0 Option TwinViewXineramaInfoOrder CRT-0 Option metamodes CRT-1: nvidia-auto-select @1280x1024 +0+0 SubSection Display Depth 24 Modes 1280x1024 EndSubSection EndSection ___ 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
EXA performance problem
Hi, I still have a huge performance problem with Xorg. One application that painted 2 Mio rectangles on the screen within a second or so with XFree86 needs about a minute with Xorg. Most of the time is spent in libpixman. I've added some debug statements and see that pixman_raster_op is called about 7.2 mio times during my testcase. I do not think that pixman itself is the problem. It is just used too often by EXA. Is there anything I can do about this? Is there a better list where I can ask? Or do you know a person that might be interested in solving such a problem? Christoph ___ 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 performance problem
On Sun, Nov 27, 2011 at 3:55 PM, Christoph Bartoschek bartosc...@or.uni-bonn.de wrote: Hi, I still have a huge performance problem with Xorg. One application that painted 2 Mio rectangles on the screen within a second or so with XFree86 needs about a minute with Xorg. Most of the time is spent in libpixman. I've added some debug statements and see that pixman_raster_op is called about 7.2 mio times during my testcase. I do not think that pixman itself is the problem. It is just used too often by EXA. Is there anything I can do about this? Is there a better list where I can ask? Or do you know a person that might be interested in solving such a problem? Christoph ___ 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: madman2...@gmail.com As far as i know it basically boils down to this, rendering rectangles is done in a software library as you observed. If your pixmap happens to be outside normal ram then a lot of reads will kill performance. These days the aim should be to use as little core rendering as possible. A modern toolkit or a rendering library like cairo should handle this far better. -- Far away from the primal instinct, the song seems to fade away, the river get wider between your thoughts and the things we do and say. ___ 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 performance problem
On Sun, 27 Nov 2011 15:55:12 +0100, Christoph Bartoschek bartosc...@or.uni-bonn.de wrote: Hi, I still have a huge performance problem with Xorg. One application that painted 2 Mio rectangles on the screen within a second or so with XFree86 needs about a minute with Xorg. The easiest way for anyone else to reproduce this issue would be if you were to identify the most common slow op and translate that into the appropriate x11perf command line. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ 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 performance problem
Am 27.11.2011 16:13, schrieb Maarten Maathuis: On Sun, Nov 27, 2011 at 3:55 PM, Christoph Bartoschek bartosc...@or.uni-bonn.de wrote: Hi, I still have a huge performance problem with Xorg. One application that painted 2 Mio rectangles on the screen within a second or so with XFree86 needs about a minute with Xorg. Most of the time is spent in libpixman. I've added some debug statements and see that pixman_raster_op is called about 7.2 mio times during my testcase. I do not think that pixman itself is the problem. It is just used too often by EXA. Is there anything I can do about this? Is there a better list where I can ask? Or do you know a person that might be interested in solving such a problem? Christoph ___ 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: madman2...@gmail.com As far as i know it basically boils down to this, rendering rectangles is done in a software library as you observed. If your pixmap happens to be outside normal ram then a lot of reads will kill performance. These days the aim should be to use as little core rendering as possible. A modern toolkit or a rendering library like cairo should handle this far better. How can I check whether the pixmap is outside the normal ram? For me it does not look as if pixman is used for rendering the image. It looks as if EXA is managing the region that needs updates with pixman routines. But I could be wrong here. Christoph ___ 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 performance problem
On Sun, Nov 27, 2011 at 9:40 PM, Christoph Bartoschek bartosc...@or.uni-bonn.de wrote: Am 27.11.2011 16:13, schrieb Maarten Maathuis: On Sun, Nov 27, 2011 at 3:55 PM, Christoph Bartoschek bartosc...@or.uni-bonn.de wrote: Hi, I still have a huge performance problem with Xorg. One application that painted 2 Mio rectangles on the screen within a second or so with XFree86 needs about a minute with Xorg. Most of the time is spent in libpixman. I've added some debug statements and see that pixman_raster_op is called about 7.2 mio times during my testcase. I do not think that pixman itself is the problem. It is just used too often by EXA. Is there anything I can do about this? Is there a better list where I can ask? Or do you know a person that might be interested in solving such a problem? Christoph ___ 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: madman2...@gmail.com As far as i know it basically boils down to this, rendering rectangles is done in a software library as you observed. If your pixmap happens to be outside normal ram then a lot of reads will kill performance. These days the aim should be to use as little core rendering as possible. A modern toolkit or a rendering library like cairo should handle this far better. How can I check whether the pixmap is outside the normal ram? For me it does not look as if pixman is used for rendering the image. It looks as if EXA is managing the region that needs updates with pixman routines. But I could be wrong here. Christoph Only the driver knows that. If you know what driver it is, you can also figure out if the driver handles pixmap allocation themselves. Then you can see if they (are likely) to use dedicated video ram, which is the only uncached memory (=slow read) i can think of right now. I don't know off the top of my head how to determine if a pixmap is offscreen (for a driver that allocates pixmaps this means that the pixmap is under driver control, the alternative is that it's a malloc private to exa). -- Far away from the primal instinct, the song seems to fade away, the river get wider between your thoughts and the things we do and say. ___ 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: What will happen when the X server doesn't support XKB(XKEYBOARD)
On Mon, Nov 21, 2011 at 07:35:21PM +0800, Adam Q wrote: There is a X server for win32 which doesn't support XKB extension(I know it's unbelievable). There is something strange when I try to use the gnome-keyboard-properties and system-config-keyboard to change the X server's keyboard layout. When using gnome-keyboard-properties,the input of keyboard goes crazy and can't be used. When using system-config-keyboard the CLI just prints something like XKB extension unsupported and nothing changed including the keyboard layout. I tested serveral X server from the latest Xorg server in Arch and some old Xorg server in RHEL5.6/5.5 also with latest cygwin/X. All the servers I tested above can change the keyboard using these 2 GUI. I assume the problem is the lack of XKB extension but without XKB extension,the client should just send a lot of ChangeKeyboardLayout requests (and wireshark shows it really sends) to X server,and the layout should change even without the XKB extension and no crazy keyboard. How can I determine where the problem really is? possibly with xmodmap to get the keyboard mapping before/after and maybe xscope or something to snoop the protocol traffic. though a server without XKB support is not really high on the priority list for server or client developers and I expect this to be a rather untested scenario. 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: EXA performance problem
I have new information. I am no longer sure whether it is a problem with EXA. I have a testcase that currently takes 90 seconds to draw all rectangles. I see that in damage.c two functions are mainly used: damagePolyRectangle damagePolyFillRectangle The first function calls for each given rectangle up to four times damageDamageBox (pDrawable, box, pGC-subWindowMode); which adds the box to a region. The function then calls damageRegionAppend. This part takes in sum 30 seconds of my testcase. I think the code has quadratic behaviour here becuase it adds rectangle by rectangle instead of first adding them to a region and then calling damageRegionAppend. I think removing the quadratic behaviour can reduce the runtime significantly. About 60 seconds are spent in the calls (*pGC-ops-PolyRectangle)(pDrawable, pGC, nRects, pRects); (*pGC-ops-PolyFillRect)(pDrawable, pGC, nRects, pRects); However I do not yet know why they are so slow. Is damage.c part of EXA? Christoph ___ 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: [ANNOUNCE] xorg-server 1.11.99.1
On Mon, 28 Nov 2011 11:39:31 +1000, Peter Hutterer peter.hutte...@who-t.net wrote: We probably won't get X Input 2.2 done if the release is moved forward to Feb 8th. What's the date for the merge window end? If we followed the 1.11 schedule, the non-critical bug window would close three weeks earlier (Jan 18), and the merge window two months before that (Nov 18), which is now nine days past... If you think X Input 2.2 is nearly ready for merging , I'd say we should go for it and get that merged by Christmas, then plan on closing the non-critical bug window in the first week of February and then finish the release in the first week of March. If you don't think X Input 2.2 will be ready by then, we should probably just close out the merge window earlier, and plan on getting the release out the door by the time I go biking. -- keith.pack...@intel.com pgpbqiHoUCd8C.pgp Description: PGP signature ___ 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: [ANNOUNCE] xorg-server 1.11.99.1
On Sun, Nov 27, 2011 at 07:29:53PM -0800, Keith Packard wrote: On Mon, 28 Nov 2011 11:39:31 +1000, Peter Hutterer peter.hutte...@who-t.net wrote: We probably won't get X Input 2.2 done if the release is moved forward to Feb 8th. What's the date for the merge window end? If we followed the 1.11 schedule, the non-critical bug window would close three weeks earlier (Jan 18), and the merge window two months before that (Nov 18), which is now nine days past... If you think X Input 2.2 is nearly ready for merging , I'd say we should go for it and get that merged by Christmas, then plan on closing the non-critical bug window in the first week of February and then finish the release in the first week of March. If you don't think X Input 2.2 will be ready by then, we should probably just close out the merge window earlier, and plan on getting the release out the door by the time I go biking. I think Christmas is realistic for the merge. We're quite some way there, but pointer emulation and the resulting grab hilarity is still missing (Chase has worked on this while I was away but I haven't looked at the current state yet) 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: [ANNOUNCE] xorg-server 1.11.99.1
On Mon, 28 Nov 2011 13:36:35 +1000, Peter Hutterer peter.hutte...@who-t.net wrote: On Sun, Nov 27, 2011 at 07:29:53PM -0800, Keith Packard wrote: On Mon, 28 Nov 2011 11:39:31 +1000, Peter Hutterer peter.hutte...@who-t.net wrote: We probably won't get X Input 2.2 done if the release is moved forward to Feb 8th. What's the date for the merge window end? If we followed the 1.11 schedule, the non-critical bug window would close three weeks earlier (Jan 18), and the merge window two months before that (Nov 18), which is now nine days past... If you think X Input 2.2 is nearly ready for merging , I'd say we should go for it and get that merged by Christmas, then plan on closing the non-critical bug window in the first week of February and then finish the release in the first week of March. If you don't think X Input 2.2 will be ready by then, we should probably just close out the merge window earlier, and plan on getting the release out the door by the time I go biking. I think Christmas is realistic for the merge. We're quite some way there, but pointer emulation and the resulting grab hilarity is still missing (Chase has worked on this while I was away but I haven't looked at the current state yet) I'd say we should go for it then. I'll plan on checking my inbox for critical patches while I'm on my bike trip, but we haven't had a lot of patches in that window in the past, so I don't expect things to back up much. -- keith.pack...@intel.com pgp5iObDYmU22.pgp Description: PGP signature ___ 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 performance problem
On Mon, Nov 28, 2011 at 2:41 AM, Christoph Bartoschek bartosc...@or.uni-bonn.de wrote: I have new information. I am no longer sure whether it is a problem with EXA. I have a testcase that currently takes 90 seconds to draw all rectangles. I see that in damage.c two functions are mainly used: damagePolyRectangle damagePolyFillRectangle The first function calls for each given rectangle up to four times damageDamageBox (pDrawable, box, pGC-subWindowMode); which adds the box to a region. The function then calls damageRegionAppend. This part takes in sum 30 seconds of my testcase. I think the code has quadratic behaviour here becuase it adds rectangle by rectangle instead of first adding them to a region and then calling damageRegionAppend. I think removing the quadratic behaviour can reduce the runtime significantly. About 60 seconds are spent in the calls (*pGC-ops-PolyRectangle)(pDrawable, pGC, nRects, pRects); (*pGC-ops-PolyFillRect)(pDrawable, pGC, nRects, pRects); However I do not yet know why they are so slow. Is damage.c part of EXA? Christoph ___ 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: madman2...@gmail.com No, damage is an extention, it is called by EXA, it's probably adding all you rectangles to a damage region used to determine how much data is actually valid (needed for ram--vram migrations for example). One thing that just comes to mind, if you are rendering a million rectangles, how many of those do you actually see on your screen? Anyway, you can try optimizing damaga, exa and either fb or mi (for PolyRectangle PolyFillRect software ops). I don't know how efficient the region code is at reducing the number of rectangles if they overlap, a region is built up out of rectangles as well. -- Far away from the primal instinct, the song seems to fade away, the river get wider between your thoughts and the things we do and say. ___ 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 performance problem
On Mon, Nov 28, 2011 at 7:43 AM, Maarten Maathuis madman2...@gmail.com wrote: On Mon, Nov 28, 2011 at 2:41 AM, Christoph Bartoschek bartosc...@or.uni-bonn.de wrote: I have new information. I am no longer sure whether it is a problem with EXA. I have a testcase that currently takes 90 seconds to draw all rectangles. I see that in damage.c two functions are mainly used: damagePolyRectangle damagePolyFillRectangle The first function calls for each given rectangle up to four times damageDamageBox (pDrawable, box, pGC-subWindowMode); which adds the box to a region. The function then calls damageRegionAppend. This part takes in sum 30 seconds of my testcase. I think the code has quadratic behaviour here becuase it adds rectangle by rectangle instead of first adding them to a region and then calling damageRegionAppend. I think removing the quadratic behaviour can reduce the runtime significantly. About 60 seconds are spent in the calls (*pGC-ops-PolyRectangle)(pDrawable, pGC, nRects, pRects); (*pGC-ops-PolyFillRect)(pDrawable, pGC, nRects, pRects); However I do not yet know why they are so slow. Is damage.c part of EXA? Christoph ___ 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: madman2...@gmail.com No, damage is an extention, it is called by EXA, it's probably adding all you rectangles to a damage region used to determine how much data is actually valid (needed for ram--vram migrations for example). One thing that just comes to mind, if you are rendering a million rectangles, how many of those do you actually see on your screen? Anyway, you can try optimizing damaga, exa and either fb or mi (for PolyRectangle PolyFillRect software ops). I don't know how efficient the region code is at reducing the number of rectangles if they overlap, a region is built up out of rectangles as well. -- Far away from the primal instinct, the song seems to fade away, the river get wider between your thoughts and the things we do and say. s/damaga/damage and s/extention/extension and s/you rectangles/your rectangles It was too early in the morning :-) -- Far away from the primal instinct, the song seems to fade away, the river get wider between your thoughts and the things we do and say. ___ 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
Disabling EXA
Hi, how can I disable EXA and use XAA? I am on opensuse and added the following section to /etc/X11/xorg.conf.d/50-device.conf: Section Device Option AccelMethod xaa Identifier Default Device EndSection Xorg reads the file because it says in its logfile: [21.481] (==) RADEON(0): Depth 24, (--) framebuffer bpp 32 [21.481] (II) RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps) [21.481] (==) RADEON(0): Default visual is TrueColor [21.481] (**) RADEON(0): Option AccelMethod xaa [21.481] (==) RADEON(0): RGB weight 888 [21.481] (II) RADEON(0): Using 8 bits per RGB (8 bit DAC) [21.481] (--) RADEON(0): Chipset: ATI Radeon Mobility X300 (M22) 5460 (PCIE) (ChipID = 0x5460) [21.481] (II) RADEON(0): PCIE card detected But EXA is still used: [21.481] (II) Loading sub module exa [21.481] (II) LoadModule: exa [21.482] (II) Loading /usr/lib/xorg/modules/libexa.so [21.488] (II) Module exa: vendor=X.Org Foundation [21.488]compiled for 1.10.4, module version = 2.5.0 ... [21.575] (II) RADEON(0): EXA: Driver will allow EXA pixmaps in VRAM ... [21.635] (II) RADEON(0): Setting EXA maxPitchBytes [21.635] (II) EXA(0): Driver allocated offscreen pixmaps [21.635] (II) EXA(0): Driver registered support for the following operations: [21.635] (II) Solid [21.635] (II) Copy [21.635] (II) Composite (RENDER acceleration) [21.635] (II) UploadToScreen [21.635] (II) DownloadFromScreen How can I disable EXA and use XAA?. I suspect EXA to be responsible for a huge performance regression. Thanks Christoph ___ 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
hdmi output not detected by xrandr
Hi I'm trying to figure out why the external hdmi output on my laptop doesn't work but am not sure where the problem is or if this is the right mailing list. I've posted on distribution specific forums asking the same question but there hasn't been any response that leads to a fix. As far as understand xrandr should be able to detect an external monitor irrespective of what is in the xorg.conf file. This is the output from xrandr when the monitor is connected to the laptop over the hdmi cable: Screen 0: minimum 320 x 200, current 1920 x 1080, maximum 8192 x 8192 LVDS1 connected 1920x1080+0+0 (normal left inverted right x axis y axis) 344mm x 193mm 1920x1080 60.0*+ 40.0 1400x1050 60.0 1280x1024 60.0 1280x960 60.0 1024x768 60.0 800x60060.3 56.2 640x48059.9 VGA1 disconnected (normal left inverted right x axis y axis) HDMI2 disconnected (normal left inverted right x axis y axis) DP1 disconnected (normal left inverted right x axis y axis) Only the laptop's display is detected. The vga controllers on the laptop are: 01:00.0 VGA compatible controller: nVidia Corporation Device 0df5 (rev a1) (prog-if 00 [VGA controller]) Subsystem: Dell Device 0446 Flags: bus master, fast devsel, latency 0, IRQ 16 Memory at f000 (32-bit, non-prefetchable) [size=16M] Memory at c000 (64-bit, prefetchable) [size=256M] Memory at d000 (64-bit, prefetchable) [size=32M] I/O ports at 3000 [size=128] Expansion ROM at f100 [disabled] [size=512K] Capabilities: access denied Kernel driver in use: nouveau Kernel modules: nvidiafb, nouveau00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) (prog-if 00 [VGA controller]) Subsystem: Dell Device 0446 Flags: bus master, fast devsel, latency 0, IRQ 49 Memory at f140 (64-bit, non-prefetchable) [size=4M] Memory at e000 (64-bit, prefetchable) [size=256M] I/O ports at 4000 [size=64] Expansion ROM at unassigned [disabled] Capabilities: access denied Kernel driver in use: i915 Kernel modules: i915 Any pointers about the correct diagnoistic path to take would be great. Thanks ___ 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: hdmi output not detected by xrandr
On Sun, 27 Nov 2011 16:01:52 +1100, sashan sas...@zenskg.net wrote: Hi I'm trying to figure out why the external hdmi output on my laptop doesn't work but am not sure where the problem is or if this is the right mailing list. I'd bet money that the hdmi connector is only hooked up to the nVidia device, which means you'd have to use that one to display anything over that connector. -- keith.pack...@intel.com pgpO0ePXw16ja.pgp Description: PGP signature ___ 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: hdmi output not detected by xrandr
On Sat Nov 26 22:13:49 2011, Keith Packard wrote: On Sun, 27 Nov 2011 16:01:52 +1100, sashan sas...@zenskg.net wrote: Hi I'm trying to figure out why the external hdmi output on my laptop doesn't work but am not sure where the problem is or if this is the right mailing list. I'd bet money that the hdmi connector is only hooked up to the nVidia device, which means you'd have to use that one to display anything over that connector. Yeah that might be the case but the document http://www.nvidia.com/object/LO_optimus_whitepapers.html about nvidia optimus basically says that the datapath to the physical monitor is always through the Intel IGP and then the IGP is responsible for writing to the display. The nVidia chip is between the application and the IGP, therefore I expected that the IGP would be connected to the HDMI port. However I'm probably wrong and would appreciate if you or someone could clarify my understanding about how this is meant to work. The laptop is a Dell XPS 15z (http://reviews.cnet.com/laptops/dell-xps-15z/4507-3121_7-34714594.html) ___ 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
Problem starting two X servers
Hello, I am trying to set a multi-seat station under Kubuntu 10.04, so i'm starting from the basics, starting two separate X servers in a station with two videocards. In my xorg.conf i have two ServerLayouts, correctly separated. I can start the video in the onboard card, but not on the offboard. I'm using the following command: startx -- :0 -layout seat 0 (:1 and seat1 for the offboard card). The error found on the log : (II) SMI(0): Output LVDS connected (WW) SMI(0): Unable to find initial modes (EE) SMI(0): Output LVDS enabled but has no modes (EE) SMI(0): No valid modes found (II) UnloadModule: siliconmotion (EE) Screen(s) found, but none have a usable configuration. The funny thing is, this same xorg.conf has already worked with this videocard in this station. Is there any other relevant config file that i'm missing? Anybody faced the same problem, or has any suggestion of a solution? Below i provide more info that i think it's relevant. Thanks in advance. [ ]'s Caio Here is my xorg.1.log http://pastebin.com/e1q3XxdH Here is my relevant lspci and xorg.conf: http://pastebin.com/RxRAaDz7 I am following this website guideline, its mostly the same as any other multi-seat guide i could find. https://www.cs.drexel.edu/node/17042 I am using the package xf86-video-siliconmotion found in this repo: http://cgit.freedesktop.org/xorg/driver/xf86-video-siliconmotion/log/?h=master More specifically this version http://cgit.freedesktop.org/xorg/driver/xf86-video-siliconmotion/tag/?id=xf86-video-siliconmotion-1.7.4 I can't use the last version because of the xorg-macros, couldnt find how to update for the last version under 10.04. ___ 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: Cannot setup dual monitors
Sorry! I got that to work. I had not installed mesa-utils. This seemed to solve this problem. However, my graphics is quite slow. Text scrolls slowly in Iceweasel. I checked glxgears and got only 400fps in windowed view and about 50fps in full screen. All this time, my processor utilzation is only 20%. So, Its not a processor problem. I tried removing xorg.conf, - I get the same performance. Can I edit xorg.conf and add in special statements to help speedup my graphics? Thanks Githin On 11/23/11, Githin Alapatt git...@gmail.com wrote: Hello, I recently upgraded from lenny to squeeze and I no longer can get my external monitor working correctly on my laptop. lspci gives these 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c) 00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c) lsmod gives: githin@debian-githin:~$ lsmod Module Size Used by parport_pc 15799 0 ppdev 4058 0 lp 5570 0 parport22554 3 parport_pc,ppdev,lp acpi_cpufreq4951 1 cpufreq_conservative 4018 0 cpufreq_powersave602 0 cpufreq_stats 1997 0 cpufreq_userspace 1480 0 rfcomm 25199 0 sco 5885 2 bridge 33031 0 stp 996 1 bridge bnep7452 2 l2cap 21721 6 rfcomm,bnep crc16 1027 1 l2cap bluetooth 36319 6 rfcomm,sco,bnep,l2cap uinput 4796 1 fuse 44268 3 arc4 974 2 ecb 1405 2 b43 132615 0 ssb33714 1 b43 pcmcia 16194 2 b43,ssb rng_core2178 1 b43 mac80211 123586 1 b43 cfg80211 87637 2 b43,mac80211 pcmcia_core20450 3 b43,ssb,pcmcia firewire_sbp2 9647 0 loop9769 0 joydev 6739 0 snd_hda_codec_idt 35329 1 snd_hda_codec_intelhdmi 9027 1 snd_hda_intel 16823 1 snd_hda_codec 46002 3 snd_hda_codec_idt,snd_hda_codec_intelhdmi,snd_hda_intel snd_hwdep 4054 1 snd_hda_codec snd_pcm_oss28671 0 snd_mixer_oss 10461 1 snd_pcm_oss snd_pcm47226 3 snd_hda_intel,snd_hda_codec,snd_pcm_oss snd_seq_midi3576 0 snd_rawmidi12513 1 snd_seq_midi snd_seq_midi_event 3684 1 snd_seq_midi snd_seq35463 2 snd_seq_midi,snd_seq_midi_event snd_timer 12270 2 snd_pcm,snd_seq snd_seq_device 3673 3 snd_seq_midi,snd_rawmidi,snd_seq i915 223022 0 drm_kms_helper 18569 1 i915 uvcvideo 45554 0 drm 111992 2 i915,drm_kms_helper i2c_algo_bit3497 1 i915 videodev 25605 1 uvcvideo dell_laptop 1557 0 rfkill 10264 4 bluetooth,cfg80211,dell_laptop i2c_i8016462 0 dcdbas 3892 1 dell_laptop v4l1_compat10250 2 uvcvideo,videodev snd34423 14 snd_hda_codec_idt,snd_hda_codec_intelhdmi,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_rawmidi,snd_seq,snd_timer,snd_seq_device wmi 3575 0 button 3598 1 i915 i2c_core 12787 6 i915,drm_kms_helper,drm,i2c_algo_bit,videodev,i2c_i801 pcspkr 1207 0 psmouse44809 0 evdev 5609 17 serio_raw 2916 0 battery 3782 0 video 14605 1 i915 output 1204 1 video soundcore 3450 1 snd ac 1640 0 snd_page_alloc 5045 2 snd_hda_intel,snd_pcm processor 26327 3 acpi_cpufreq ext3 94396 2 jbd32317 1 ext3 mbcache 3762 1 ext3 sg 19937 0 sr_mod 10770 0 cdrom 26487 1 sr_mod sd_mod 26005 5 crc_t10dif 1012 1 sd_mod ata_generic 2247 0 uhci_hcd 16057 0 ahci 27410 4 sdhci_pci 4581 0 sdhci 12171 1 sdhci_pci mmc_core 38685 3 b43,ssb,sdhci ricoh_mmc 2561 0 led_class 1757 2 b43,sdhci firewire_ohci 16725 0 firewire_core 31243 2 firewire_sbp2,firewire_ohci crc_itu_t 1035 1 firewire_core ata_piix 17736 0 ehci_hcd 28693 0 sky2 34040 0 libata115869 3 ata_generic,ahci,ata_piix scsi_mod 104853 5
RE: The PCI device 0x10de087d (ION) at 02@00:00:0 has a kernel module claiming it.
Thanks for reply, as you told there is nouveau driver block my driver. Is this possible to unload it? All the best, Anatolii Ivashyna -Original Message- From: Aaron Plattner [mailto:aplatt...@nvidia.com] Sent: Tuesday, November 22, 2011 6:43 PM To: Anatolii Ivashyna Cc: x...@freedesktop.org Subject: Re: The PCI device 0x10de087d (ION) at 02@00:00:0 has a kernel module claiming it. Check the output of lsmod for modules that can claim that device. It's probably either nvidia or nouveau. I think you can find out for sure by running readlink /sys/bus/pci/devices/:02:00.0/driver Unload the conflicting driver and try again. On 11/22/2011 02:58 AM, Anatolii Ivashyna wrote: Hi all, I use ION nettop, and have this message in boot.log when using xorg7-nv driver. Linux: Thinstation, kernel ver: 3.0.9TS Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. (==) Log file: /var/log/Xorg.0.log, Time: Tue Nov 22 12:48:34 2011 (++) Using config file: /etc/X11/x.config-0 (==) Using config directory: /etc/X11/xorg.conf.d (EE) NV: The PCI device 0x10de087d (ION) at 02@00:00:0 has a kernel module claiming it. (EE) NV: This driver cannot operate until it has been unloaded. (EE) No devices detected. Please help! *All the best,* *Anatolii Ivashyna* ___ 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
Cannot setup dual monitors
Hello, I recently upgraded from lenny to squeeze and I no longer can get my external monitor working correctly on my laptop. lspci gives these 00:02.0 VGA compatible controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c) 00:02.1 Display controller: Intel Corporation Mobile GM965/GL960 Integrated Graphics Controller (rev 0c) lsmod gives: githin@debian-githin:~$ lsmod Module Size Used by parport_pc 15799 0 ppdev 4058 0 lp 5570 0 parport22554 3 parport_pc,ppdev,lp acpi_cpufreq4951 1 cpufreq_conservative 4018 0 cpufreq_powersave602 0 cpufreq_stats 1997 0 cpufreq_userspace 1480 0 rfcomm 25199 0 sco 5885 2 bridge 33031 0 stp 996 1 bridge bnep7452 2 l2cap 21721 6 rfcomm,bnep crc16 1027 1 l2cap bluetooth 36319 6 rfcomm,sco,bnep,l2cap uinput 4796 1 fuse 44268 3 arc4 974 2 ecb 1405 2 b43 132615 0 ssb33714 1 b43 pcmcia 16194 2 b43,ssb rng_core2178 1 b43 mac80211 123586 1 b43 cfg80211 87637 2 b43,mac80211 pcmcia_core20450 3 b43,ssb,pcmcia firewire_sbp2 9647 0 loop9769 0 joydev 6739 0 snd_hda_codec_idt 35329 1 snd_hda_codec_intelhdmi 9027 1 snd_hda_intel 16823 1 snd_hda_codec 46002 3 snd_hda_codec_idt,snd_hda_codec_intelhdmi,snd_hda_intel snd_hwdep 4054 1 snd_hda_codec snd_pcm_oss28671 0 snd_mixer_oss 10461 1 snd_pcm_oss snd_pcm47226 3 snd_hda_intel,snd_hda_codec,snd_pcm_oss snd_seq_midi3576 0 snd_rawmidi12513 1 snd_seq_midi snd_seq_midi_event 3684 1 snd_seq_midi snd_seq35463 2 snd_seq_midi,snd_seq_midi_event snd_timer 12270 2 snd_pcm,snd_seq snd_seq_device 3673 3 snd_seq_midi,snd_rawmidi,snd_seq i915 223022 0 drm_kms_helper 18569 1 i915 uvcvideo 45554 0 drm 111992 2 i915,drm_kms_helper i2c_algo_bit3497 1 i915 videodev 25605 1 uvcvideo dell_laptop 1557 0 rfkill 10264 4 bluetooth,cfg80211,dell_laptop i2c_i8016462 0 dcdbas 3892 1 dell_laptop v4l1_compat10250 2 uvcvideo,videodev snd34423 14 snd_hda_codec_idt,snd_hda_codec_intelhdmi,snd_hda_intel,snd_hda_codec,snd_hwdep,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_rawmidi,snd_seq,snd_timer,snd_seq_device wmi 3575 0 button 3598 1 i915 i2c_core 12787 6 i915,drm_kms_helper,drm,i2c_algo_bit,videodev,i2c_i801 pcspkr 1207 0 psmouse44809 0 evdev 5609 17 serio_raw 2916 0 battery 3782 0 video 14605 1 i915 output 1204 1 video soundcore 3450 1 snd ac 1640 0 snd_page_alloc 5045 2 snd_hda_intel,snd_pcm processor 26327 3 acpi_cpufreq ext3 94396 2 jbd32317 1 ext3 mbcache 3762 1 ext3 sg 19937 0 sr_mod 10770 0 cdrom 26487 1 sr_mod sd_mod 26005 5 crc_t10dif 1012 1 sd_mod ata_generic 2247 0 uhci_hcd 16057 0 ahci 27410 4 sdhci_pci 4581 0 sdhci 12171 1 sdhci_pci mmc_core 38685 3 b43,ssb,sdhci ricoh_mmc 2561 0 led_class 1757 2 b43,sdhci firewire_ohci 16725 0 firewire_core 31243 2 firewire_sbp2,firewire_ohci crc_itu_t 1035 1 firewire_core ata_piix 17736 0 ehci_hcd 28693 0 sky2 34040 0 libata115869 3 ata_generic,ahci,ata_piix scsi_mod 104853 5 firewire_sbp2,sg,sr_mod,sd_mod,libata usbcore98969 4 uvcvideo,uhci_hcd,ehci_hcd nls_base4541 1 usbcore thermal 9206 0 thermal_sys 9378 3 video,processor,thermal githin@debian-githin:~$ githin@debian-githin:~$ cat /etc/X11/xorg.conf # xorg.conf (X.Org X Window System server configuration file) # # This file was generated by dexconf, the Debian X Configuration tool, using # values from the debconf database. # # Edit this file with caution, and see the xorg.conf manual page. # (Type man xorg.conf at the shell prompt.) # # This file is automatically updated on xserver-xorg package upgrades
Re: The PCI device 0x10de087d (ION) at 02@00:00:0 has a kernel module claiming it.
On Wed, Nov 23, 2011 at 4:48 AM, Anatolii Ivashyna t...@aurora.com.ua wrote: Thanks for reply, as you told there is nouveau driver block my driver. Is this possible to unload it? All the best, Anatolii Ivashyna Is it not possible to just use the nouveau driver instead of nv? nv is pretty much unmaintained at this point, but nouveau is supported by the nouveau team, and more importantly, your distro apparently supports nouveau too. ~ C. -- When the facts change, I change my mind. What do you do, sir? ~ Keynes Corbin Simpson mostawesomed...@gmail.com ___ 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
[ANNOUNCE] s3switch 0.1
From: Tormod Volden debian.tor...@gmail.com From: Tormod Volden debian.tor...@gmail.com -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 This is a new release of s3switch, a tool to manipulate video output on S3 Savage cards, written by Tim Roberts. This release mainly incorporates fixes and enhancements found in the Debian and Fedora packages. Guido Guenther (6): Add clean rule to Makefile Move s3switch.1x man page to s3switch.8 Add proper copyright notice Fix includes in s3switch.c to kill gcc warnings Let TVout work on ProSavageDDR Use CFLAGS in Makefile Tim Roberts (1): Imported Tim Roberts' original code Tormod Volden (6): lrmi.c: Apply lrmi upstream fix to build on 2.6.26+ Add missing format string for printf copyright: Delete duplicated text Update lrmi.c and lrmi.h from upstream CVS Move privilege check to after arguments parsing Add -V option to print version Ville Skyttä (2): Avoid segfault on TV signal format change with ThinkPad T23 Patch from GeeXboX 0.97 for ViRGE/GX2 support git tree: http://people.freedesktop.org/~tormod/s3switch/ git tag: s3switch-0.1 http://people.freedesktop.org/~tormod/s3switch/s3switch-0.1.tar.bz2 MD5: 264584c73d56035eef7ad25f9683d506 s3switch-0.1.tar.bz2 SHA1: 5c0272a8a837e0f0c151f05d00e6f7e35c5a s3switch-0.1.tar.bz2 SHA256: 485013b165568a8d8d5f14c9d9b7c54ba1cb3b4b11e17b827df87b54f0c2459e s3switch-0.1.tar.bz2 http://people.freedesktop.org/~tormod/s3switch/s3switch-0.1.tar.gz MD5: b69842b45d66640706a041fc304753c2 s3switch-0.1.tar.gz SHA1: 83976a1ad2e66a1c88b1d605b90a5df577e45816 s3switch-0.1.tar.gz SHA256: fd9d5d848aae2c80be4d8d929e366abeab771dd549e281eb2fe833c2962246c9 s3switch-0.1.tar.gz -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.11 (GNU/Linux) iEYEARECAAYFAk7ILtUACgkQoy2Edrr0HQwsLACeJxD5aaSU8iUDDKZxrk98IMNS CdEAoOxkqT1xMmXjPagKX1JvBXYyIbsv =7esL -END PGP SIGNATURE- ___ xorg-announce mailing list xorg-announce@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce
Re: Failed to compile keymap using ptxdist
thing is i cant find xkbcomp in menuconfig or kernelconfig.. i searched through.. is there an easy way to identify where the packages menu entry would be? [Wilson Wingston Sharon] On Mon, Nov 21, 2011 at 1:30 PM, Dirk Wallenstein hals...@t-online.de wrote: On Fri, Nov 18, 2011 at 02:09:17PM +0530, Wingston Sharon wrote: I'm using the pengutronix ptxdist BSP for the mini2440 and i wanted to set up an xwindow system. but got this error.. when trying to start Xorg.. i have enabled anxkeymap entry in menuconfig but i cant find a keymap entry in eithermenuconfig or kernelconfig.doing a ptxdist clean xorg and then ptxdist go doesnt help either.. asin ptxdist says that theres nothing to be done for world. (==) Logfile: /var/log/Xorg.0.log, Time: Thu Oct 2 23:41:35 2008(==) Using config file: /etc/X11/xorg.conf(==) Using system config directory/usr/lib/X11/xorg.conf.dsh: /usr/bin/xkbcomp: not found(EE) Error compiling keymap (server-0)(EE) XKB: Couldn't compile Sounds like you need to install xkbcomp. keymap XKB: Failed to compile keymap Keyboard initialization failed. This could be amissing or incorrect setup of x. Fatal server error: Failed to activate core devices.-doing a little more digging around i came across the xorg -configureoption.. this though gives me this little gem of knowledge.. root@mini2440:~ Xorg -configure X.Org X Server 1.9.3Release Date: 2010-12-13X Protocol Version 11, Revision 0Build Operating System:Linux- PtxdistCurrent Operating System: Linux mini2440 3.1.1-ptx-2011.11.0 #0 PREEMPT Fri NovlKernel command line: console=ttySAC0,115200 mini2440=6tbc ip=192.168.1.2:192.16)Build Date: 18 November 2011 11:37:52AM Current version of pixman: 0.21.2 Before reporting problems, check http://www.pengutronix.de/software/ptxl to make sure that you have the latest version.Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown.(==) Log file: /var/log/Xorg.0.log, Time: Thu Oct 2 23:53:52 2008List ofvideo drivers: dummy v4l fbdev No devices to configure. Configuration failed. ---i gues my device is fbdev.. but i'm stumped how i would be able to getit to configure the xorg.config file.[Wilson Wingston Sharon] -- Cheers, Dirk ___ 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
