[PATCH] XKB: cache xkbcomp output for fast start-up v4 for 1.6.0
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 yan.i...@intel.com
---
configure.ac|6 +-
xkb/README.compiled |8 +-
xkb/ddxLoad.c | 188 +--
3 files changed, 160 insertions(+), 42 deletions(-)
diff --git a/configure.ac b/configure.ac
index f2718b8..5d8a6e5 100644
--- a/configure.ac
+++ b/configure.ac
@@ -476,9 +476,9 @@ AC_ARG_WITH(default-font-path,
AS_HELP_STRING([--with-default-font-path=PATH], [
AC_ARG_WITH(xkb-path, AS_HELP_STRING([--with-xkb-path=PATH], [Path to
XKB base dir (default: ${datadir}/X11/xkb)]),
[ XKBPATH=$withval ],
[ XKBPATH=${datadir}/X11/xkb ])
-AC_ARG_WITH(xkb-output, AS_HELP_STRING([--with-xkb-output=PATH], [Path
to XKB output dir (default: ${datadir}/X11/xkb/compiled)]),
+AC_ARG_WITH(xkb-output, AS_HELP_STRING([--with-xkb-output=PATH], [Path
to XKB output dir (default: ${localstatedir}/cache/xkb)]),
[ XKBOUTPUT=$withval ],
- [ XKBOUTPUT=compiled ])
+ [ XKBOUTPUT=${localstatedir}/cache/xkb ])
AC_ARG_WITH(serverconfig-path, AS_HELP_STRING([--with-serverconfig-path=PATH],
[Directory where ancillary server config
files are installed (default: ${libdir}/xorg)]),
[ SERVERCONFIG=$withval ],
@@ -1753,7 +1753,7 @@ AC_DEFINE_DIR(XKB_BIN_DIRECTORY, bindir, [Path to XKB bin
dir])
XKBOUTPUT_FIRSTCHAR=`echo $XKBOUTPUT | cut -b 1`
if [[ x$XKBOUTPUT_FIRSTCHAR != x/ ]] ; then
- XKBOUTPUT=$XKB_BASE_DIRECTORY/$XKBOUTPUT
+ AC_MSG_ERROR([xkb-output must be an absolute path.])
fi
# XKM_OUTPUT_DIR (used in code) must end in / or file names get hosed
diff --git a/xkb/README.compiled b/xkb/README.compiled
index 71caa2f..a4a2ae0 100644
--- a/xkb/README.compiled
+++ b/xkb/README.compiled
@@ -4,10 +4,10 @@ current keymap and/or any scratch keymaps used by clients.
The X server
or some other tool might destroy or replace the files in this directory,
so it is not a safe place to store compiled keymaps for long periods of
time. The default keymap for any server is usually stored in:
- Xnum-default.xkm
-where num is the display number of the server in question, which makes
-it possible for several servers *on the same host* to share the same
-directory.
+ server-SHA1.xkm
+
+where SHA1 is the SHA1 hash of keymap source, so that compiled
+keymap of different keymap sources are stored in different files.
Unless the X server is modified, sharing this directory between servers on
different hosts could cause problems.
diff --git a/xkb/ddxLoad.c b/xkb/ddxLoad.c
index 4d5dfb6..4c22f4f 100644
--- a/xkb/ddxLoad.c
+++ b/xkb/ddxLoad.c
@@ -32,6 +32,12 @@ THE USE OR PERFORMANCE OF THIS SOFTWARE.
#include xkb-config.h
#endif
+#ifdef HAVE_SHA1_IN_LIBMD /* Use libmd for SHA1 */
+# include sha1.h
+#else /* Use OpenSSL's libcrypto */
+# include stddef.h /* buggy openssl/sha.h wants size_t */
+# include openssl/sha.h
+#endif
#include stdio.h
#include ctype.h
#defineNEED_EVENTS 1
@@ -46,24 +52,13 @@ THE USE OR PERFORMANCE OF THIS SOFTWARE.
#defineXKBSRV_NEED_FILE_FUNCS
#include xkbsrv.h
#include X11/extensions/XI.h
+#include errno.h
#include xkb.h
#if defined(CSRG_BASED) || defined(linux) || defined(__GNU__)
#include paths.h
#endif
- /*
-* If XKM_OUTPUT_DIR specifies a path without a leading slash, it is
-* relative to the top-level XKB configuration directory.
-* Making the server write to a subdirectory of that directory
-* requires some work in the general case (install procedure
-* has to create links to /var or somesuch on many machines),
-* so we just compile into /usr/tmp for now.
-*/
-#ifndef XKM_OUTPUT_DIR
-#defineXKM_OUTPUT_DIR compiled/
-#endif
-
#definePRE_ERROR_MSG \The XKEYBOARD keymap compiler (xkbcomp)
reports:\
#defineERROR_PREFIX\ \
#definePOST_ERROR_MSG1 \Errors from xkbcomp are not fatal to the X
server\
@@ -179,6 +174,45 @@ OutputDirectory(
}
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
Re: luit forked?
Alan Coopersmith wrote:
: http://invisible-island.net/luit/luit.html
: http://cgit.freedesktop.org/xorg/app/luit
:
: Is there any reason we should have two forks of this? Which one
: do most distros ship?
Fedora ships the second one:
$ rpm -qf `which luit`
xorg-x11-apps-7.3-5.fc10.x86_64
A colleague told me that this is true also for Ubuntu (so
presumably for Debian too).
-Yenya
--
| Jan Yenya Kasprzak kas at {fi.muni.cz - work | yenya.net - private} |
| GPG: ID 1024/D3498839 Fingerprint 0D99A7FB206605D7 8B35FCDE05B18A5E |
| http://www.fi.muni.cz/~kas/Journal: http://www.fi.muni.cz/~kas/blog/ |
If you find yourself arguing with Alan Cox, you’re _probably_ wrong.
--James Morris in How and Why You Should Become a Kernel Hacker
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
xrandr tmds_pll option with radeon?
Hi there, last night i updated x.org-server to 1.5.3 on my Thinkpad R51 running Gentoo Linux, Kernel 2.6.27.12, with radeon driver. Before the update i executed the following at fvwm startup: xrandr --output DVI-0 --set tmds_pll driver xrandr --output DVI-0 --mode 1600x1200 --rate 60.0 Without this, my NEC 2090UXi TFT-Display attached via Dockingstation only allows 1280x1024 as maximum resolution. If i tried to do xrandr --output DVI-0 --mode 1600x1200 --rate 60.0 the display turns black and doesn't show anything. After searching in google, i found a post on a mailinglist with xrandr --output DVI-0 --set tmds_pll driver and with this command everything worked fine. But now with the new xorg-server version xrandr says: $ xrandr --output DVI-0 --set tmds_pll driver X Error of failed request: BadName (named color or font does not exist) Major opcode of failed request: 150 (RANDR) Minor opcode of failed request: 11 () Serial number of failed request: 19 Current serial number in output stream: 19 So it is not possible to set the TFT resolution to 1600x1200, again black display. Maybe someone knows where the tmds_pll option is gone? Kind regards, robert -- Robert Uhl ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] libdrm 2.4.7
Hi, tests/drmtest.c still not compile under fedora 10, code seems to depends on the new udev. Did I need new udev for the rest of libdrm ? Thanks, On Thu, 2009-04-09 at 15:23 -0400, Kristian Høgsberg wrote: Ok, here's a quick follow on release to 2.4.6 to fix an embarrasing build problem in the test suite when libudev is not available. Kristian Dave Airlie (1): drm: fix test makefile Kristian Høgsberg (3): test: Makefile.am grammar nazi test: Avoid recursive dependency in makefile Bump version to 2.4.7 git tag: libdrm-2.4.7 http://dri.freedesktop.org/libdrm/libdrm-2.4.7.tar.bz2 MD5: 696007a9090c237fd8e6c8ee84d897d7 libdrm-2.4.7.tar.bz2 SHA1: 8a82d5652ff88fa482bf4fda630d14e983f3d294 libdrm-2.4.7.tar.bz2 http://dri.freedesktop.org/libdrm/libdrm-2.4.7.tar.gz MD5: d680f92c4dd1232b750c1b2247331b50 libdrm-2.4.7.tar.gz SHA1: 4c16f0a542193d838130e0a8900ce358430f44a6 libdrm-2.4.7.tar.gz ___ xorg-announce mailing list xorg-annou...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce -- Sérgio M. B. smime.p7s Description: S/MIME cryptographic signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: luit forked?
On Fri, Apr 10, 2009 at 11:17:43AM +0200, Jan Kasprzak wrote: Alan Coopersmith wrote: : http://invisible-island.net/luit/luit.html : http://cgit.freedesktop.org/xorg/app/luit : : Is there any reason we should have two forks of this? Which one : do most distros ship? Fedora ships the second one: $ rpm -qf `which luit` xorg-x11-apps-7.3-5.fc10.x86_64 A colleague told me that this is true also for Ubuntu (so presumably for Debian too). Same for openSUSE (luit 1.0.3). Best regards, Stefan Public Key available -- Stefan Dirsch (Res. Dev.) SUSE LINUX Products GmbH Tel: 0911-740 53 0Maxfeldstraße 5 FAX: 0911-740 53 479 D-90409 Nürnberg http://www.suse.deGermany - SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) - ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[Question] vesa driver with RandR 1.2
Dear list, I am currently using xserver-xorg-video-vesa 1.3.0 along with xrandr 1.2 on one of my laptop. It is to my curiosity that is there any support on RandR in vesa driver since it seems to fail detecting an external monitor. I have taken a look on the git tree of vesa driver and it seems that support for RandR 1.2 is on the TODO list. http://cgit.freedesktop.org/xorg/driver/xf86-video-vesa/tree/src/vesa.c vesa.c ... snip ... /* * TODO: * - PanelID might give us useful size hints. * - Port to RANDR 1.2 setup to make mode selection slightly better * - Port to RANDR 1.2 to drop the old-school DGA junk * - VBE/SCI for secondary DDC method? */ ... snip ... Is there any means to use the external monitor with vesa driver? -- Sincerely, Jyo ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: luit forked?
Is there any reason we should have two forks of this? Which one do most distros ship? pkgsrc ships X.org version. NetBSD ships X.org version. (But I don't think they knew of other version.) ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xrandr tmds_pll option with radeon?
On 4/10/09, Robert Uhl r@xaipete.de wrote: Hi there, last night i updated x.org-server to 1.5.3 on my Thinkpad R51 running Gentoo Linux, Kernel 2.6.27.12, with radeon driver. Before the update i executed the following at fvwm startup: xrandr --output DVI-0 --set tmds_pll driver xrandr --output DVI-0 --mode 1600x1200 --rate 60.0 Without this, my NEC 2090UXi TFT-Display attached via Dockingstation only allows 1280x1024 as maximum resolution. If i tried to do xrandr --output DVI-0 --mode 1600x1200 --rate 60.0 the display turns black and doesn't show anything. After searching in google, i found a post on a mailinglist with xrandr --output DVI-0 --set tmds_pll driver and with this command everything worked fine. But now with the new xorg-server version xrandr says: $ xrandr --output DVI-0 --set tmds_pll driver X Error of failed request: BadName (named color or font does not exist) Major opcode of failed request: 150 (RANDR) Minor opcode of failed request: 11 () Serial number of failed request: 19 Current serial number in output stream: 19 So it is not possible to set the TFT resolution to 1600x1200, again black display. Maybe someone knows where the tmds_pll option is gone? Sorry typo in the code associated it with the wrong tmds encoder. It's fixed in xf86-video-ati git. Alex ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [Question] vesa driver with RandR 1.2
On 4/10/09, Kan-I Jyo cecilhs...@gmail.com wrote: Dear list, I am currently using xserver-xorg-video-vesa 1.3.0 along with xrandr 1.2 on one of my laptop. It is to my curiosity that is there any support on RandR in vesa driver since it seems to fail detecting an external monitor. I have taken a look on the git tree of vesa driver and it seems that support for RandR 1.2 is on the TODO list. http://cgit.freedesktop.org/xorg/driver/xf86-video-vesa/tree/src/vesa.c vesa.c ... snip ... /* * TODO: * - PanelID might give us useful size hints. * - Port to RANDR 1.2 setup to make mode selection slightly better * - Port to RANDR 1.2 to drop the old-school DGA junk * - VBE/SCI for secondary DDC method? */ ... snip ... Is there any means to use the external monitor with vesa driver? If you boot with your laptop lid closed, you can probably get the external display to work with vesa. Multi-head is not really possible with vesa. If you want multi-head or the ability to switch outputs, use a native driver for your hardware. Alex ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] libdrm 2.4.7
On Fri, 2009-04-10 at 10:16 +0100, Sergio Monteiro Basto wrote: Hi, tests/drmtest.c still not compile under fedora 10, code seems to depends on the new udev. Did I need new udev for the rest of libdrm ? It is built and released on FreeBSD and I don't have udev for sure... robert. Thanks, On Thu, 2009-04-09 at 15:23 -0400, Kristian Høgsberg wrote: Ok, here's a quick follow on release to 2.4.6 to fix an embarrasing build problem in the test suite when libudev is not available. Kristian Dave Airlie (1): drm: fix test makefile Kristian Høgsberg (3): test: Makefile.am grammar nazi test: Avoid recursive dependency in makefile Bump version to 2.4.7 git tag: libdrm-2.4.7 http://dri.freedesktop.org/libdrm/libdrm-2.4.7.tar.bz2 MD5: 696007a9090c237fd8e6c8ee84d897d7 libdrm-2.4.7.tar.bz2 SHA1: 8a82d5652ff88fa482bf4fda630d14e983f3d294 libdrm-2.4.7.tar.bz2 http://dri.freedesktop.org/libdrm/libdrm-2.4.7.tar.gz MD5: d680f92c4dd1232b750c1b2247331b50 libdrm-2.4.7.tar.gz SHA1: 4c16f0a542193d838130e0a8900ce358430f44a6 libdrm-2.4.7.tar.gz ___ xorg-announce mailing list xorg-annou...@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg-announce ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg -- Robert Noland rnol...@2hip.net 2 Hip Networks signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xserver doesn't support XvPutImage to Pixmap?
On Fri, 2009-04-10 at 17:30 +0800, Yuan Austin wrote: I tried to comment above two lines, then XvPutImage can draw into a pixmap. I am not sure if it has side effect. No, I think that's a good patch. Can you post it to the X.org bugzilla against the X server so I can track that into a release? I saw this a year ago but it wasn't put into the bug system and got lost. -- keith.pack...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xserver doesn't support XvPutImage to Pixmap?
I think Xv is meant to also work for overlays, which obviously won't
work on a pixmap. Maybe it's a safety so application developers don't
do anything stupid.
Maarten.
On Fri, Apr 10, 2009 at 11:30 AM, Yuan Austin shengquan.y...@gmail.com wrote:
On Thu, Apr 2, 2009 at 3:59 PM, Shengquan Yuan shengquan.y...@gmail.com
wrote:
Hi,
I tried to use XvPutImage to draw into a pixmap, but it always returns
error. After tracing into Xserver, I found function
hw/xfree86/common/xf86xv.c:xf86XVPutImage checks whether the drawable
is WINDOW, if not, it returns BadAlloc directly, see bellow code:
static int
xf86XVPutImage(
ClientPtr client,
DrawablePtr pDraw,
XvPortPtr pPort,
GCPtr pGC,
INT16 src_x, INT16 src_y,
CARD16 src_w, CARD16 src_h,
INT16 drw_x, INT16 drw_y,
CARD16 drw_w, CARD16 drw_h,
XvImagePtr format,
unsigned char* data,
Bool sync,
CARD16 width, CARD16 height
){
XvPortRecPrivatePtr portPriv = (XvPortRecPrivatePtr)(pPort-devPriv.ptr);
ScreenPtr pScreen;
RegionRec WinRegion;
RegionRec ClipRegion;
BoxRec WinBox;
int ret = Success;
Bool clippedAway = FALSE;
if (pDraw-type != DRAWABLE_WINDOW)
= return BadAlloc;
I tried to comment above two lines, then XvPutImage can draw into a
pixmap. I am not sure if it has side effect.
I also tried intel driver on a 945G platform, since intel driver is
using UXA architecture, and bellow exaMoveInPixmap won't be called,
this hacking doesn't work.
I also looked at Xvideo implementation in Xserver video driver, and it
looks like texture video supports rendering into a pixmap:
if (pDraw-type == DRAWABLE_WINDOW)
pPriv-pPixmap = (*pScreen-GetWindowPixmap)((WindowPtr)pDraw);
else
pPriv-pPixmap = (PixmapPtr)pDraw;
#ifdef USE_EXA
if (info-useEXA) {
/* Force the pixmap into framebuffer so we can draw to it. */
exaMoveInPixmap(pPriv-pPixmap);
}
#endif
I am wondering what's the reason that Xserver returns failure directly
when XvPutImage drawing into a pixmap?
Thanks
Austin
___
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: Xserver doesn't support XvPutImage to Pixmap?
On Fri, 2009-04-10 at 19:05 +0200, Maarten Maathuis wrote: I think Xv is meant to also work for overlays, which obviously won't work on a pixmap. Maybe it's a safety so application developers don't do anything stupid. Drivers are welcome to limit what applications can do with Xv, but the core X server shouldn't prohibit legal operations like this (which can work with some Xv backends, just not overlays). Of course, older Xv implementations couldn't support pixmaps. -- keith.pack...@intel.com signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
On Wed, 2009-04-08 at 17:41 -0400, Gene Heskett wrote: I have NDI why they just can't send the pw to my recorded email addy and leave it otherwise alone. I'd imagine for the same reason that you can't just read other user's passwords from /etc/(passwd,shadow): they are stored hashed so that leaking the password data doesn't leak the passwords themselves. Ross -- Ross Burton mail: r...@burtonini.com jabber: r...@burtonini.com www: http://burtonini.com ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[ANNOUNCE] xf86-video-intel 2.6.99.903
Here is the third release candidate in preparation for the upcoming 2.7.0 release. As before, the main improvements since the 2.6-series driver include: SDVO-TV support, available on ADD2 card (bug#9992) and D945GCLF2 board (bug#17776). Basic SDVO-LVDS support Tearing-free xv (bug#19635) For for panel startup failure on some specific laptop models (bug#17292) and various fixes for UXA/DRI2 and Kernel Modesetting. Please give it a try and report bugs as usual (referring to http://intellinuxgraphics.org/how_to_report_bug.html). The remaining bugs we plan to fix before release 2.7.0 are being tracked here (5 remaining at the time of this writing): http://bugs.freedesktop.org/show_bug.cgi?id=intel-2d-release The URL above also links to some 25 bugs fixed during the 2.7 process so far. Many of which are noted in the log below. We offer our thanks to the many users, bug reporters, and engineers working so hard to improve our driver! -Carl PS. If you can think major bugs or features that should be give prominent notice in the final release notes, (in addition to the four above, please let me know). Getting the code git tag: 2.6.99.903 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.6.99.903.tar.bz2 MD5: e6a261d35b15dfb8eceeccd1c5f473d2 xf86-video-intel-2.6.99.903.tar.bz2 SHA1: 662354005e36e42ded4a01bb51c9dce976e38e2a xf86-video-intel-2.6.99.903.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-intel-2.6.99.903.tar.gz MD5: 328816c418c1163565f0e094c030f5aa xf86-video-intel-2.6.99.903.tar.gz SHA1: 2d2d59f40f27ff5acfdd650347df2a01a28f5614 xf86-video-intel-2.6.99.903.tar.gz Summary of all changes since 2.6.99.902 --- Albert Damen (1): Non-GEM allocations incorrectly force TILE_NONE (bug 20797) Carl Worth (5): Use WAIT_FOR_SCAN_LINE instead of WAIT_FOR_VBLANK Remove support for 'auto'(-1) value of XV_SYNC_TO_VBLANK Fix new video sync-to-blank code for multi-head Don't clip video to CRTC in the case of textured video Increment version to 2.6.99.903 for release Dan Nicholson (1): Fix dist of xvmc sources Eric Anholt (1): Fix XV with non-GEM kernels by allocating a larger fake bufmgr. Hugo Jacques (1): SDVO: add composite TV out support Jesse Barnes (10): Use UXA when KMS is active Create known output configuration at EnterVT time Re-enable disabled outputs after rotation Don't install fences if the kernel is managing them Don't manage fences part two Tiling fixes, third set Require libdrm 2.4.6 for GTT unmap support Match GTT unmap with map in KMS rotation case Fix offset in begin_gtt_access case Don't enable kernel execbuf fencing w/EXA Kalev Lember (2): Fix Xv crash with overlay video. Fix VT switch with XV overlay video enabled. Keith Packard (1): Use CopyArea to load glyphs from per-glyph pixmap to cache pixmap Kristian Høgsberg (1): Drop Legacy3D option, only use fixed texture space with non-gem. Ma Ling (3): Set SSC frequency for 8xx chips correctly Define documented PLL timing limits for G4X platform Use best PLL timing values for G4X platform Ma, Ling (1): disable center mode for 965GM and G4X platform Rémi Cardona (1): clean up man page generation and remove all traces of the i810 driver Shuang He (1): Fix value for MI_WAIT_FOR_PIPEA_SCAN_LINE_WINDOW Zhenyu Wang (9): SDVO: fix pixel multiplier setting for TV SDVO: reset privates before output setup Revert SDVO: Switch control bus only before DDC access TV: force TV as connected with TV_Connector option TV: fix contrast and saturation for 945G Disable LVDS config parsing from VBT for now Disable LVDS detect methods SDVO: fix output flag dumping for unknown type quirk LVDS on ibase MB890 855GM board signature.asc Description: This is a digitally signed message part ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
