[PATCH] Patch to not fork/exec xkbcomp on X Server initialization
This is the patch that I wrote for Moblin as part of the efforts of
fast-boot to save some load time of X server: xkbcomp outputs will be
cached in files with hashed keymap as names (using SHA1). This saves
boot time for around 1s on commodity netbooks. It is made against
1.6.0.
I haven't read Paulo's latest patch that uses SHA1 as file names until
I've finished my own (though I do have read early versions of his
patch). Interestingly that we've employed similar idea.
Comparing to Paulo's patch, this one is much simpler, with the goal
that touch as few things as possible. And xkbcomp's output will be
stored in /var/lib/xkb/ instead of somewhere under /usr/.
In this patch there are also corrections to wrongly used TAB for
indention of codes related to this function. If you don't like it I
can move them to another standalone patch.
I understood the difficulty of merging functions like this into
mainstream. Or if we need to add an option to make this behaviour
optional, rather than enabled by default. I'd like to follow on this
until people is happy with it.
Welcome comments.
--
Li, Yan
From e7046c26d7ac970bfd75cae16262845bef72423b Mon Sep 17 00:00:00 2001
From: Yan Li
Date: Tue, 24 Mar 2009 17:43:12 +0800
Subject: [PATCH] Cache xkbcomp output for fast start-up
xkbcomp outputs will be cached in files with hashed keymap as
names. This saves boot time for around 1s on commodity netbooks.
Signed-off-by: Yan Li
---
xkb/ddxLoad.c | 188 +---
xkb/xkbfmisc.c | 18 +-
2 files changed, 153 insertions(+), 53 deletions(-)
diff --git a/xkb/ddxLoad.c b/xkb/ddxLoad.c
index 4d5dfb6..799622d 100644
--- a/xkb/ddxLoad.c
+++ b/xkb/ddxLoad.c
@@ -32,6 +32,12 @@ THE USE OR PERFORMANCE OF THIS SOFTWARE.
#include
#endif
+#ifdef HAVE_SHA1_IN_LIBMD /* Use libmd for SHA1 */
+# include
+#else /* Use OpenSSL's libcrypto */
+# include /* buggy openssl/sha.h wants size_t */
+# include
+#endif
#include
#include
#define NEED_EVENTS 1
@@ -159,25 +165,61 @@ OutputDirectory(
size_t size)
{
#ifndef WIN32
-if (getuid() == 0 && (strlen(XKM_OUTPUT_DIR) < size))
-{
- /* if server running as root it *may* be able to write */
- /* FIXME: check whether directory is writable at all */
- (void) strcpy (outdir, XKM_OUTPUT_DIR);
+if (getuid() == 0 && (strlen(XKM_OUTPUT_DIR) < size)) {
+/* if server running as root it *may* be able to write */
+/* FIXME: check whether directory is writable at all */
+(void) strcpy (outdir, XKM_OUTPUT_DIR);
} else
#else
-if (strlen(Win32TempDir()) + 1 < size)
-{
- (void) strcpy(outdir, Win32TempDir());
- (void) strcat(outdir, "\\");
+if (strlen(Win32TempDir()) + 1 < size) {
+(void) strcpy(outdir, Win32TempDir());
+(void) strcat(outdir, "\\");
} else
#endif
-if (strlen("/tmp/") < size)
-{
- (void) strcpy (outdir, "/tmp/");
+if (strlen("/tmp/") < size) {
+(void) strcpy (outdir, "/tmp/");
+}
+}
+
+static Bool
+Sha1Asc(char sha1Asc[SHA_DIGEST_LENGTH*2+1], const char * input)
+{
+int i;
+unsigned char sha1[SHA_DIGEST_LENGTH];
+
+#ifdef HAVE_SHA1_IN_LIBMD /* Use libmd for SHA1 */
+SHA1_CTX ctx;
+
+SHA1Init (&ctx);
+SHA1Update (&ctx, input, strlen(input));
+SHA1Final (sha1, &ctx);
+#else /* Use OpenSSL's libcrypto */
+SHA_CTX ctx;
+int success;
+
+success = SHA1_Init (&ctx);
+if (! success)
+ return BadAlloc;
+
+success = SHA1_Update (&ctx, input, strlen(input));
+if (! success)
+ return BadAlloc;
+
+success = SHA1_Final (sha1, &ctx);
+if (! success)
+ return BadAlloc;
+#endif
+
+/* convert sha1 to sha1_asc */
+for(i=0; i nameRtrnLen) && nameRtrn) {
+ErrorF("[xkb] nameRtrn too small to hold xkmfile name\n");
+return False;
+}
+strncpy(nameRtrn, xkmfile, nameRtrnLen);
+
+/* if the xkb file already exists, reuse it */
+canonicalXkmfileName = Xprintf("%s%s.xkm", xkmOutputDir, xkmfile);
+LogMessage(X_INFO, "[xkb] xkmfile %s ", canonicalXkmfileName);
+if (access(canonicalXkmfileName, R_OK) == 0) {
+/* yes, we can reuse old xkb file */
+LogMessage(X_INFO, "reused\n");
+xfree(canonicalXkmfileName);
+return True;
+}
+LogMessage(X_INFO, "is being compiled\n");
+xfree(canonicalXkmfileName);
-XkbEnsureSafeMapName(keymap);
-OutputDirectory(xkm_output_dir, sizeof(xkm_output_dir));
+/* continue to call xkbcomp to compile the keymap */
#ifdef WIN32
strcpy(tmpname, Win32TempDir());
@@ -215,19 +302,19 @@ XkbDDXCompileKeymapByNames( XkbDescPtr xkb,
#endif
if (XkbBaseDirectory != NULL) {
- xkbbasedirflag = Xprintf("\"-R%s\"", XkbBaseDirectory);
+xkbbasedirflag = Xprintf("\"-R%s\"", XkbBaseDirectory);
}
if (XkbBinDirectory != NULL) {
- int ld = strlen(XkbBinDirectory);
- int lps = strlen(PATHSEPARATOR);
+int ld = strlen(XkbBinDirectory);
+int lps
Re: Kernel modesetting
On Tue, Mar 24, 2009 at 17:47:22 -0500, tsuraan wrote: > > I assume you use RandR instead of Xinerama. > > Does RandR do monitor placement as well as the normal Resize and > Rotate? I'll have to see if I have it enabled on my machine... "RandR" is an abbreviation for "Resize and Rotate". Regards, Tino ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: How can I exclude the X default mode in RandR ?
On 3/24/09, gordony...@viatech.com.cn wrote: > Alex, > Thanks for your kind help. > But it won't support the user-define mode lines, because they are also > excluded. > For example, > Section "Monitor" > > Modeline "1024x768_60.00" ... > EndSection > The mode "1024x768_60.00" will be filtered. It may be a limitation. > We can't have a method to make the best of both worlds. > I think user defined modes should have the M_T_USERDEF flag set. Alex > Best wishes, > Gordon > > -Original Message- > From: xorg-boun...@lists.freedesktop.org > [mailto:xorg-boun...@lists.freedesktop.org] On Behalf Of Alex Deucher > Sent: 2009年3月24日 21:47 > To: Gordon Yuan > Cc: x...@freedesktop.org > Subject: Re: How can I exclude the X default mode in RandR ? > > On 3/24/09, gordony...@viatech.com.cn wrote: > > Alex, > > Thanks! > > Because HDMI doesn't support GTF timing, the X default modes are > all excluded on XServer 1.6. > > I still have no idea how to filter them on XServer 1.5.x. I can filter > certain mode, but I can't filter all the X default modes. > > > > In your mode_valid() function, compare the mode passed in to the modes > in the edid. if it doesn't match, return MODE_BAD. > > Alex > > > Best wishes, > > Gordon > > > > > > -Original Message- > > From: Alex Deucher [mailto:alexdeuc...@gmail.com] > > Sent: 2009年3月23日 21:54 > > To: Gordon Yuan > > Cc: x...@freedesktop.org > > Subject: Re: How can I exclude the X default mode in RandR ? > > > > On 3/23/09, gordony...@viatech.com.cn wrote: > > > > > > > > > > > > > > > Dear all, > > > > > > In RandR, X will include the default mode (xf86DefaultModes) in the > mode > > > list. But it’s not useful for some devices (e.g. TV or HDMI). How can I > > > delete these modes from the mode list? I don’t want to output these > modes if > > > I press the command “xrandr -q”. > > > > > > It’s X behavior. It seems that driver can’t change the logic. > > > > > > Thanks! > > > > xserver 1.6 and newer only add the default modes if the edid has the > > continuous frequency bit set. If you don't want to add certain modes, > > you can filter what gets added in your driver's mode_valid() function. > > > > Alex > > > > > ___ > xorg mailing list > xorg@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg > ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Two cursor using Xinerama on XServer 1.5.99.3
On Fri, Mar 13, 2009 at 03:09:06PM +0800, gordony...@viatech.com.cn wrote:
> I tried as you said. There is only ONE cursor on the screen, but it's a
> software cursor, not hardware. The codes about hardware cursor are not
> called at all. In fact, only one hardware cursor is what I want. Please
> give me some advice. By the way, is there something about my driver or
> xorg code?
This fixes it on my box, please give it a test.
>From 3323f7ac880d5a8261d5b22059374fc9de8ca683 Mon Sep 17 00:00:00 2001
From: Peter Hutterer
Date: Wed, 25 Mar 2009 12:55:42 +1000
Subject: [PATCH] xfree86: fix SWCursor check in xf86CursorSetCursor.
Wrong check for inputInfo.pointer resulted in a SW cursor being rendered when
the pointer left the screen (in a Xinerama setup).
We must call the sprite rendering function if
- SW cursors are enabled, or
- The current device is not the VCP and not attached to the VCP.
Reported-by: Gordon Yuan
Signed-off-by: Peter Hutterer
---
hw/xfree86/ramdac/xf86Cursor.c |6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/hw/xfree86/ramdac/xf86Cursor.c b/hw/xfree86/ramdac/xf86Cursor.c
index 2b73b16..896ed37 100644
--- a/hw/xfree86/ramdac/xf86Cursor.c
+++ b/hw/xfree86/ramdac/xf86Cursor.c
@@ -302,9 +302,9 @@ xf86CursorSetCursor(DeviceIntPtr pDev, ScreenPtr pScreen,
CursorPtr pCurs,
if (pCurs == NullCursor) { /* means we're supposed to remove the cursor */
-if (ScreenPriv->SWCursor || pDev != inputInfo.pointer)
-(*ScreenPriv->spriteFuncs->SetCursor)(pDev, pScreen, NullCursor,
- x, y);
+if (ScreenPriv->SWCursor ||
+!(pDev == inputInfo.pointer || !pDev->isMaster && pDev->u.master
== inputInfo.pointer))
+(*ScreenPriv->spriteFuncs->SetCursor)(pDev, pScreen,
NullCursor, x, y);
else if (ScreenPriv->isUp) {
xf86SetCursor(pScreen, NullCursor, x, y);
ScreenPriv->isUp = FALSE;
--
1.6.0.6
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
RE: How can I exclude the X default mode in RandR ?
Alex, Thanks for your kind help. But it won't support the user-define mode lines, because they are also excluded. For example, Section "Monitor" Modeline "1024x768_60.00" ... EndSection The mode "1024x768_60.00" will be filtered. It may be a limitation. We can't have a method to make the best of both worlds. Best wishes, Gordon -Original Message- From: xorg-boun...@lists.freedesktop.org [mailto:xorg-boun...@lists.freedesktop.org] On Behalf Of Alex Deucher Sent: 2009年3月24日 21:47 To: Gordon Yuan Cc: x...@freedesktop.org Subject: Re: How can I exclude the X default mode in RandR ? On 3/24/09, gordony...@viatech.com.cn wrote: > Alex, > Thanks! > Because HDMI doesn't support GTF timing, the X default modes are all > excluded on XServer 1.6. > I still have no idea how to filter them on XServer 1.5.x. I can filter > certain mode, but I can't filter all the X default modes. > In your mode_valid() function, compare the mode passed in to the modes in the edid. if it doesn't match, return MODE_BAD. Alex > Best wishes, > Gordon > > > -Original Message- > From: Alex Deucher [mailto:alexdeuc...@gmail.com] > Sent: 2009年3月23日 21:54 > To: Gordon Yuan > Cc: x...@freedesktop.org > Subject: Re: How can I exclude the X default mode in RandR ? > > On 3/23/09, gordony...@viatech.com.cn wrote: > > > > > > > > > > Dear all, > > > > In RandR, X will include the default mode (xf86DefaultModes) in the > mode > > list. But it’s not useful for some devices (e.g. TV or HDMI). How can I > > delete these modes from the mode list? I don’t want to output these modes > if > > I press the command “xrandr -q”. > > > > It’s X behavior. It seems that driver can’t change the logic. > > > > Thanks! > > xserver 1.6 and newer only add the default modes if the edid has the > continuous frequency bit set. If you don't want to add certain modes, > you can filter what gets added in your driver's mode_valid() function. > > Alex > > ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Virtual screen on LVDS - Aspire One
Sorry to repeat myself since I asked this the other day and didn't get any response so I'm asking again and if I don't have the right information here, hopefully someone will let me know. Acer Aspire One... The object is to have a larger virtual screen than the built in LVDS 1024x600, perhaps 1024x768 or 1280x1024 but I can't seem to make that happen. Fedora 10, i386, various rpm packages including (and I may have been too aggressive removing some from this list)... # rpm -qa|grep xorg xorg-x11-font-utils-7.2-6.fc10.i386 xorg-x11-drv-fbdev-0.3.1-7.fc9.i386 xorg-x11-drv-fpit-1.2.0-1.fc9.i386 xorg-x11-drv-digitaledge-1.1.1-1.fc9.i386 xorg-x11-drivers-7.3-9.fc10.i386 xorg-x11-server-Xorg-1.5.3-15.fc10.i386 xorg-x11-drv-vesa-2.0.0-1.fc10.i386 xorg-x11-drv-i810-2.5.0-4.fc10.i386 xorg-x11-fonts-ISO8859-1-75dpi-7.2-6.fc9.noarch xorg-x11-drv-keyboard-1.3.2-1.fc10.i386 xorg-x11-drv-evdev-2.1.3-1.fc10.i386 xorg-x11-server-common-1.5.3-15.fc10.i386 xorg-x11-filesystem-7.3-2.fc10.noarch xorg-x11-xkb-utils-7.2-7.fc10.i386 xorg-x11-utils-7.4-3.fc10.i386 xorg-x11-apps-7.3-5.fc10.i386 xorg-x11-xauth-1.0.2-5.fc10.i386 xorg-x11-xinit-1.0.9-4.fc10.i386 xorg-x11-drv-mouse-1.3.0-2.fc9.i386 xorg-x11-drv-s3virge-1.10.0-1.fc9.i386 xorg-x11-server-utils-7.4-3.fc10.i386 xorg-x11-drv-i128-1.3.0-1.fc9.i386 xorg-x11-drv-apm-1.2.0-1.fc9.i386 xorg-x11-xdm-1.1.6-6.fc10.i386 nothing I have done so far has allowed me to have a virtual screen on the LVDS larger than 1024x600. Presently xorg.conf on my Aspire One looks like this... Section "ServerLayout" Identifier "single head configuration" Screen 0 "Screen0" 0 0 InputDevice"Keyboard0" "CoreKeyboard" EndSection Section "InputDevice" # keyboard added by rhpxl Identifier "Keyboard0" Driver "kbd" Option "XkbModel" "pc105+inet" Option "XkbLayout" "us" EndSection Section "Device" Identifier "Card0" Driver "intel" VendorName "Intel Corporation" BoardName "Mobile 945GME Express Integrated Graphics Controller" VideoRam229376 Option"MonitorLayout" "LVDS,VGA" Option"Clone" "true" #Option"AccelMethod" "EXA" Option"NoAccel" "true" Option"MigrationHeuristic" "greedy" Option"CacheLines" "1980" BusID "PCI:0:2:0" EndSection Section "Screen" Identifier "Screen0" Device "Card0" DefaultDepth 24 SubSection "Display" Viewport 0 0 Depth 24 Modes "1280x1024" "1024x768" "1024x600" Virtual 2048 2048 EndSubSection EndSection and I have had various sizes in 'Virtual' from 1024 768 and 1280 1024 and have tried disabling the 'Modes' line altogether or just had it with "1280x1024" (my 19" display) but nothing has worked. I have been mostly testing things with just the built-in display because that is where I want the larger virtual screen. ;-( Craig ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problem using libXevie
Michael Pozhidaev wrote: > X Error of failed request: BadLength (poly request too large or internal > Xlib length error) > Major opcode of failed request: 153 (XEVIE) There were a number of fixes to length checks in XEvIE, especially in byte-swapped requests from other-endian clients, that landed in the master branch last year - I'm not sure if any of them made it to a release before XEvIE support was removed from Xorg 1.6 though. If you want to try them, you could find patches in these commits: http://cgit.freedesktop.org/xorg/xserver/log/Xext/xevie.c?id=b5cdcfa55c399e83d51242e93d4f25d8bc4fec1f -- -Alan Coopersmith- alan.coopersm...@sun.com Sun Microsystems, Inc. - X Window System Engineering ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86-video-xgi-1.5.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Alfie Viechweg wrote: > What is the status of the xf86-video-xgi driver. Is it deprecated? > > I was trying to build this driver against xorg-server-1.6.0 and I notice > it's looking for a header file name xf86Version.h which does not exist > anymore. Other drivers had similar problems when this file was removed. Look at the commit log for pretty much any other driver. The changes required should be almost identical. > Also, can the xf86-video-sis driver be used instead of the xf86-video-xgi? As far as I'm aware, neither driver is actively maintained. > The hardware under consideration for this driver is the XGI processors > found on the Tyan server motherboards. That's probably a Z7 or a Z11. I don't think xf86-video-sis supports those chips. It would be easy enough to try, but I think you'll need to use xf86-video-xgi. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAknJdoIACgkQX1gOwKyEAw/P7wCfZN64TRSB5lTJ0GvSUjk56im4 es8AoJlxWg0RGcm88OKCUiQRfwkKpUfb =iHn1 -END PGP SIGNATURE- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problem using libXevie
On Wed, 2009-03-25 at 09:55 +1000, Peter Hutterer wrote: > On Wed, Mar 25, 2009 at 05:41:53AM +0600, Michael Pozhidaev wrote: > > Greetings! > > > > It is my first posting to this list. I want to discuss the problem with > > using libXevie. I use its release 1.0.2 and the snapshot published in > > Git repository at http://cgit.freedesktop.org/xorg/lib/libXevie. > > > > In both cases there is a problem with running test from > > http://people.freedesktop.org/~ajax/xevie/xevie-test.txt. > > > > When I run this test I get the following output: > > > > X Error of failed request: BadLength (poly request too large or internal > > Xlib length error) > > Major opcode of failed request: 153 (XEVIE) > > Minor opcode of failed request: 3 () > > Serial number of failed request: 11 > > Current serial number in output stream: 11 > > Delay is 0 milliseconds > > major = 1, minor = 0 > > XevieStart(dpy) finished > > ( 0) KeyRelease > > > > As I found this is a known bug, because there are corresponding reports > > in bugzilla of some Linux distributions. > > is there a bug on bugs.freedesktop.org for this? Sounds like bug#17394. Cheers, Julien ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problem using libXevie
I've actually had the same problem but was able to work around it. (http://bugs.freedesktop.org/show_bug.cgi?id=19263) -rino On Tue, Mar 24, 2009 at 6:55 PM, Peter Hutterer wrote: > On Wed, Mar 25, 2009 at 05:41:53AM +0600, Michael Pozhidaev wrote: >> Greetings! >> >> It is my first posting to this list. I want to discuss the problem with >> using libXevie. I use its release 1.0.2 and the snapshot published in >> Git repository at http://cgit.freedesktop.org/xorg/lib/libXevie. >> >> In both cases there is a problem with running test from >> http://people.freedesktop.org/~ajax/xevie/xevie-test.txt. >> >> When I run this test I get the following output: >> >> X Error of failed request: BadLength (poly request too large or internal >> Xlib length error) >> Major opcode of failed request: 153 (XEVIE) >> Minor opcode of failed request: 3 () >> Serial number of failed request: 11 >> Current serial number in output stream: 11 >> Delay is 0 milliseconds >> major = 1, minor = 0 >> XevieStart(dpy) finished >> ( 0) KeyRelease >> >> As I found this is a known bug, because there are corresponding reports >> in bugzilla of some Linux distributions. > > is there a bug on bugs.freedesktop.org for this? > > Cheers, > Peter > ___ > xorg mailing list > xorg@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg > ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Problem using libXevie
On Wed, Mar 25, 2009 at 05:41:53AM +0600, Michael Pozhidaev wrote: > Greetings! > > It is my first posting to this list. I want to discuss the problem with > using libXevie. I use its release 1.0.2 and the snapshot published in > Git repository at http://cgit.freedesktop.org/xorg/lib/libXevie. > > In both cases there is a problem with running test from > http://people.freedesktop.org/~ajax/xevie/xevie-test.txt. > > When I run this test I get the following output: > > X Error of failed request: BadLength (poly request too large or internal > Xlib length error) > Major opcode of failed request: 153 (XEVIE) > Minor opcode of failed request: 3 () > Serial number of failed request: 11 > Current serial number in output stream: 11 > Delay is 0 milliseconds > major = 1, minor = 0 > XevieStart(dpy) finished > ( 0) KeyRelease > > As I found this is a known bug, because there are corresponding reports > in bugzilla of some Linux distributions. is there a bug on bugs.freedesktop.org for this? Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Problem using libXevie
Greetings! It is my first posting to this list. I want to discuss the problem with using libXevie. I use its release 1.0.2 and the snapshot published in Git repository at http://cgit.freedesktop.org/xorg/lib/libXevie. In both cases there is a problem with running test from http://people.freedesktop.org/~ajax/xevie/xevie-test.txt. When I run this test I get the following output: X Error of failed request: BadLength (poly request too large or internal Xlib length error) Major opcode of failed request: 153 (XEVIE) Minor opcode of failed request: 3 () Serial number of failed request: 11 Current serial number in output stream: 11 Delay is 0 milliseconds major = 1, minor = 0 XevieStart(dpy) finished ( 0) KeyRelease As I found this is a known bug, because there are corresponding reports in bugzilla of some Linux distributions. But, is there any cure for this problem? The primary reason I am looking for solution, is the problem with running at-spi-registryd from the GNOME Accessibility Project. It fails with the libXevie error message. The developer from GNOME Accessibility Project, Willy Walker, says he has no idea what happens. Please, help to investigate this bug and make a solution! -- Michael Pozhidaev. E-mail: m...@altlinux.ru. Tomsk State University. http://www.csd.tsu.ru ALT Linux Team. http://www.altlinux.org ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86OSMouseInit() not used
On Mon, Mar 23, 2009 at 06:01:56PM -0500, Jeremy C. Reed wrote: > On Wed, 18 Mar 2009, Peter Hutterer wrote: > > > I think in 1.4, xf86OSMouseInit was still in the server, so maybe > > there's some conflicts there. > > That sounds like that was it. Maybe the xf86-input-mouse configure should > check for xorg-server >= 1.4.99.something instead of >= 1.0.99.901 (so it > won't even build if the conflicting xorg-server is noticed). pushed, thanks. 1.5.99.901 is required, 1.5 still had that code. Cheers, Peter ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Kernel modesetting
> I assume you use RandR instead of Xinerama. Does RandR do monitor placement as well as the normal Resize and Rotate? I'll have to see if I have it enabled on my machine... Also, does anybody (Kieth Packard?) have any info on how to run with the new kernel modesetting configuration? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Kernel modesetting
On Tue, Mar 24, 2009 at 20:54:02 +0100, Florian Mickler wrote: > On Tue, 24 Mar 2009 17:33:16 +0100 > Tino Keitel wrote: > > > On Tue, Mar 24, 2009 at 11:05:33 -0500, tsuraan wrote: > > > > [...] > > > > > be possible to use DRI and Xinerama in this configuration, or is > > > that > > > > The Intel Xorg driver doesn't work with Xinerama anymore. It just > > crashes if you enable Xinerama. The last version of the Intel driver > > I know that works with Xinerama is 1.7.4. > > > > Regards, > > Tino > > ___ > > xorg mailing list > > xorg@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/xorg > > Hi! > The Intel Xorg driver works with Xinerama. I'm writing you this half > on my 22"-Monitor and half on my Laptop's LVDS. I assume you use RandR instead of Xinerama. Regards, Tino ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Kernel modesetting
On Tue, 24 Mar 2009 17:33:16 +0100 Tino Keitel wrote: > On Tue, Mar 24, 2009 at 11:05:33 -0500, tsuraan wrote: > > [...] > > > be possible to use DRI and Xinerama in this configuration, or is > > that > > The Intel Xorg driver doesn't work with Xinerama anymore. It just > crashes if you enable Xinerama. The last version of the Intel driver > I know that works with Xinerama is 1.7.4. > > Regards, > Tino > ___ > xorg mailing list > xorg@lists.freedesktop.org > http://lists.freedesktop.org/mailman/listinfo/xorg Hi! The Intel Xorg driver works with Xinerama. I'm writing you this half on my 22"-Monitor and half on my Laptop's LVDS. And it continually worked since i bought my monitor 2 years ago. Currently I'm on the git-version of the intel-driver as of march 19th. perhaps your statement about the intel xorg-driver not working with xinerama is too broad? This version works with both, KMS and Non-KMS. The only kink is, that with KMS the output's are numbered (VGA vs VGA1 and LVDS vs LVDS1) so you have to extend your xorg-monitor-configuration for these outputs) The only bug in KMS that keeps me from defaulting to it, is http://bugs.freedesktop.org/show_bug.cgi?id=20666 (slow rxvt rendering), but i have no time to pursue this issue any further. For KMS i have updated also my xorg-server and various dependencies to the git-versions. Sincerly, Florian Mickler signature.asc Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Kernel modesetting
On Tue, Mar 24, 2009 at 16:44:24 +, Alan Cox wrote: > On Tue, 24 Mar 2009 17:33:16 +0100 > Tino Keitel wrote: > > > On Tue, Mar 24, 2009 at 11:05:33 -0500, tsuraan wrote: > > > > [...] > > > > > be possible to use DRI and Xinerama in this configuration, or is that > > > > The Intel Xorg driver doesn't work with Xinerama anymore. It just > > crashes if you enable Xinerama. The last version of the Intel driver I > > know that works with Xinerama is 1.7.4. > > Is that due to xinerama or is that the broken dual head support ? This is caused by the Intel Xorg driver as soon as Xinerama is enabled, even with only one 1024x768 display, see http://bugs.freedesktop.org/show_bug.cgi?id=10299 Regards, Tino ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Kernel modesetting
On Tue, 24 Mar 2009 17:33:16 +0100 Tino Keitel wrote: > On Tue, Mar 24, 2009 at 11:05:33 -0500, tsuraan wrote: > > [...] > > > be possible to use DRI and Xinerama in this configuration, or is that > > The Intel Xorg driver doesn't work with Xinerama anymore. It just > crashes if you enable Xinerama. The last version of the Intel driver I > know that works with Xinerama is 1.7.4. Is that due to xinerama or is that the broken dual head support ? Forcing Option "Noaccel" seems to fix the hang in X if you have > 2048 pixels width of display on Intel video (even though it claims anyway to be disabling acceleration it apparently doesn't do it right) Without that hack you can't do large displays on things like Fedora 10, only on Fedora 9 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Kernel modesetting
On Tue, Mar 24, 2009 at 11:05:33 -0500, tsuraan wrote: [...] > be possible to use DRI and Xinerama in this configuration, or is that The Intel Xorg driver doesn't work with Xinerama anymore. It just crashes if you enable Xinerama. The last version of the Intel driver I know that works with Xinerama is 1.7.4. Regards, Tino ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Kernel modesetting
I have a laptop with an intel VGA controller, and I'd like to try the new kernel modesetting from the 2.6.29 kernel. What xorg intel driver version, xorg version, etc do I need to try this out? Also, will it be possible to use DRI and Xinerama in this configuration, or is that impossible for some other reason? My Intel chip, from lspci -v: 00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07) (prog-if 00 [VGA controller]) Subsystem: Sony Corporation Device 9025 Flags: bus master, fast devsel, latency 0, IRQ 379 Memory at e840 (64-bit, non-prefetchable) [size=4M] Memory at d000 (64-bit, prefetchable) [size=256M] I/O ports at 8130 [size=8] Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Count=1/1 Enable+ Capabilities: [d0] Power Management version 3 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
xf86-video-xgi-1.5.0
What is the status of the xf86-video-xgi driver. Is it deprecated? I was trying to build this driver against xorg-server-1.6.0 and I notice it's looking for a header file name xf86Version.h which does not exist anymore. Also, can the xf86-video-sis driver be used instead of the xf86-video-xgi? The hardware under consideration for this driver is the XGI processors found on the Tyan server motherboards. Thanks. Alfie Viechweg ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
/*SUPPRESS*/ comments?
In various places in the Xorg source code see comments like this one in "./app/bitmap/Handlers.c": status->success = status->draw ? True : False; /* SUPPRESS 701 */ BWTerminateRequest(w, TRUE); What does that comments do, it kind of looks like a lint directive. Pat --- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Fwd: Commit 5100d829a4d71ce4a9fbc2b81694a1fb90066ccf causing problems with mythtv
Hi: I've been attempting to debug a bug that recently entered Ubuntu jaunty [1] related to MythTV. It seems that a whole slew of X BadMatch errors and RenderBadPicture errors are thrown out whenever a QWidget show call is used. Using git-bisect, I came to the conclusion it got introduced at this commit in the xorg-server 1.6 branch: commit 8b967b24690cb072fc37c463eceb2b886cef80c4 Author: Eric Anholt Date: Mon Feb 2 10:13:46 2009 -0800 glx: Don't match fbconfigs to visuals with mismatched channel masks. This fixes at least one known bug, where the depth 32 visual would end up with a depth 24 fbconfig attached, angering compiz. (cherry picked from commit 5100d829a4d71ce4a9fbc2b81694a1fb90066ccf) Signed-off-by: Keith Packard Having no in depth knowledge of this code, I'm at a bit of a loss of whether to point fingers at QT3 that some patch is necessary, or if this is a genuine problem with Xorg. [1] https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/341898 Regards, -- Mario Limonciello supe...@gmail.com Sent from: Austin Texas United States. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: How can I exclude the X default mode in RandR ?
On 3/24/09, gordony...@viatech.com.cn wrote: > Alex, > Thanks! > Because HDMI doesn't support GTF timing, the X default modes are all > excluded on XServer 1.6. > I still have no idea how to filter them on XServer 1.5.x. I can filter > certain mode, but I can't filter all the X default modes. > In your mode_valid() function, compare the mode passed in to the modes in the edid. if it doesn't match, return MODE_BAD. Alex > Best wishes, > Gordon > > > -Original Message- > From: Alex Deucher [mailto:alexdeuc...@gmail.com] > Sent: 2009年3月23日 21:54 > To: Gordon Yuan > Cc: x...@freedesktop.org > Subject: Re: How can I exclude the X default mode in RandR ? > > On 3/23/09, gordony...@viatech.com.cn wrote: > > > > > > > > > > Dear all, > > > > In RandR, X will include the default mode (xf86DefaultModes) in the > mode > > list. But it’s not useful for some devices (e.g. TV or HDMI). How can I > > delete these modes from the mode list? I don’t want to output these modes > if > > I press the command “xrandr -q”. > > > > It’s X behavior. It seems that driver can’t change the logic. > > > > Thanks! > > xserver 1.6 and newer only add the default modes if the edid has the > continuous frequency bit set. If you don't want to add certain modes, > you can filter what gets added in your driver's mode_valid() function. > > Alex > > ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86OSMouseInit() not used
Jeremy C. Reed wrote: > On Wed, 18 Mar 2009, Peter Hutterer wrote: >> I think in 1.4, xf86OSMouseInit was still in the server, so maybe >> there's some conflicts there. > > That sounds like that was it. Maybe the xf86-input-mouse configure should > check for xorg-server >= 1.4.99.something instead of >= 1.0.99.901 (so it > won't even build if the conflicting xorg-server is noticed). > > With the cgit.freedesktop.org interface how can I browse to the "attic" > or old bsd_mouse.c? > http://cgit.freedesktop.org/xorg/xserver/tree/hw/xfree86/os-support/bsd/bsd_mouse.c > > doesn't show me anything. Switch to e.g. server1.5 branch Peter, I re-cc'ed you to make sure you've got an eye on the above. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
RandR 1.3 support projection ?
Dear all, In RandR 1.3 introduction ppt, it's said that RandR 1.3 support projection and the transformation matrix is (1,0,0,0,1,0,0,1/d,0). That means that if the source ordinate is (x, y), the destination ordinate is (d*x/y, d). It's the projection value on the line y=d. The CRTC contents will become a line after projection. I have tested the matrix (1,0,0,0,1,0,0,0.5,0) on Intel platform. And it's not supported. Is there something wrong with the projection matrix? Thanks! Best wishes, Gordon ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
RE: How can I exclude the X default mode in RandR ?
Alex, Thanks! Because HDMI doesn't support GTF timing, the X default modes are all excluded on XServer 1.6. I still have no idea how to filter them on XServer 1.5.x. I can filter certain mode, but I can't filter all the X default modes. Best wishes, Gordon -Original Message- From: Alex Deucher [mailto:alexdeuc...@gmail.com] Sent: 2009年3月23日 21:54 To: Gordon Yuan Cc: x...@freedesktop.org Subject: Re: How can I exclude the X default mode in RandR ? On 3/23/09, gordony...@viatech.com.cn wrote: > > > > > Dear all, > > In RandR, X will include the default mode (xf86DefaultModes) in the mode > list. But it’s not useful for some devices (e.g. TV or HDMI). How can I > delete these modes from the mode list? I don’t want to output these modes if > I press the command “xrandr -q”. > > It’s X behavior. It seems that driver can’t change the logic. > > Thanks! xserver 1.6 and newer only add the default modes if the edid has the continuous frequency bit set. If you don't want to add certain modes, you can filter what gets added in your driver's mode_valid() function. Alex ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Multi-card Xorg
Hi all. For those of you who are interested in having Xorg work with multiple graphics cards, I've created a bugzilla bug to track the issue. https://bugs.freedesktop.org/show_bug.cgi?id=20816 If the issue is something you want to keep an eye on, feel free to add yourself to the CC field on the bug. HTH, - | Name: Tim Nelson | Because the Creator is,| | E-mail: wayl...@wayland.id.au| I am | - BEGIN GEEK CODE BLOCK Version 3.12 GCS d+++ s+: a- C++$ U+++$ P+++$ L+++ E- W+ N+ w--- V- PE(+) Y+>++ PGP->+++ R(+) !tv b++ DI D G+ e++> h! y- -END GEEK CODE BLOCK- ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
