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
[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 yan.i...@intel.com
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 yan.i...@intel.com
---
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 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
#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; iSHA_DIGEST_LENGTH; ++i) {
+sprintf(sha1Asc+i*2, %02X, sha1[i]);
}
+
+return Success;
}
+/* call xkbcomp and compile XKB keymap, return xkm file name in
+ nameRtrn */
static Bool
XkbDDXCompileKeymapByNames( XkbDescPtr xkb,
XkbComponentNamesPtr names,
@@ -187,7 +229,9 @@ XkbDDXCompileKeymapByNames( XkbDescPtr xkb,
int nameRtrnLen)
{
FILE * out;
-char *buf = NULL, keymap[PATH_MAX], xkm_output_dir[PATH_MAX];
+char * buf = NULL, xkmfile[PATH_MAX], xkmOutputDir[PATH_MAX];
+char sha1Asc[SHA_DIGEST_LENGTH*2+1], xkbKeyMapBuf[1024];
+int ret;
const char *emptystring = ;
const char *xkbbasedirflag = emptystring;
@@ -198,15 +242,58 @@ XkbDDXCompileKeymapByNames( XkbDescPtr xkb,
/* WIN32 has no popen. The input must be stored in a file which is
used as input for xkbcomp. xkbcomp does not read from stdin. */
char tmpname[PATH_MAX];
-const char *xkmfile = tmpname;
+const char *xkbfile = tmpname;
#else
-const char *xkmfile = -;
+const char *xkbfile = -;
#endif
+char * canonicalXkmfileName;
+
+/* Write XKBKeyMap (xkbfile contents) to xkbKeyMapBuf, of which
+ SHA1 is generated as XKB file
Re: Kernel modesetting
'Twas brillig, and Tino Keitel at 25/03/09 06:46 did gyre and gimble: 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. I think he knew that judging by what he wrote, but yes, randr 1.2/1.3 can do placement too. Just look at the output from xrandr command and the --help it provides :) Col -- Colin Guthrie gmane(at)colin.guthr.ie http://colin.guthr.ie/ Day Job: Tribalogic Limited [http://www.tribalogic.net/] Open Source: Mandriva Linux Contributor [http://www.mandriva.com/] PulseAudio Hacker [http://www.pulseaudio.org/] Trac Hacker [http://trac.edgewall.org/] ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Kernel modesetting
On Wed, Mar 25, 2009 at 07:26:13 +, Colin Guthrie wrote: 'Twas brillig, and Tino Keitel at 25/03/09 06:46 did gyre and gimble: [...] RandR is an abbreviation for Resize and Rotate. I think he knew that judging by what he wrote, but yes, randr 1.2/1.3 can do placement too. Just look at the output from xrandr command and the --help it provides :) Oh, I misread it then. Sorry. Regards, Tino ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
randr1.3 primary output using?
Dear All: Recently I am using RandR1.3, I found a little confuse with RandR1.3 primary output definition. What is this parameter for? I use the command xrandr --output VGA --primary I found if the VGA occupied the IGA2, after using the command line it occupied IGA1, see the info from xrandr --verbose Before command Screen 0: minimum 320 x 200, current 1024 x 768, maximum 2048 x 2048 VGA connected 1024x768+0+0 (0x3e) normal (normal left inverted right x axis y axis) 352mm x 264mm Identifier: 0x3a Timestamp: 584354 Subpixel: unknown Clones: CRTC: 0 CRTCs: 0 1 EDID_DATA: 00005a63133501010101 320d01031d241bbe2abbb8a352469824 0f484c8081998159714f6159a94f c140c940d140863d00c05100304040a0 13006008111e00ff00333543 3033353030303238300a00fd0032 b41e6118000a20202020202000fc 00473930662b0a2020202020202000bb TV connected 1024x768+0+0 (0x49) normal (normal left inverted right x axis y axis) 0mm x 0mm Identifier: 0x3d Timestamp: 584354 Subpixel: unknown Clones: CRTC: 1 CRTCs: 0 1 After command Screen 0: minimum 320 x 200, current 1024 x 768, maximum 2048 x 2048 CRT connected 1024x768+0+0 (0x3e) normal (normal left inverted right x axis y axis) 352mm x 264mm Identifier: 0x3a Timestamp: 584354 Subpixel: unknown Clones: CRTC: 1 CRTCs: 1 0 EDID_DATA: 00005a63133501010101 320d01031d241bbe2abbb8a352469824 0f484c8081998159714f6159a94f c140c940d140863d00c05100304040a0 13006008111e00ff00333543 3033353030303238300a00fd0032 b41e6118000a20202020202000fc 00473930662b0a2020202020202000bb TV connected 1024x768+0+0 (0x49) normal (normal left inverted right x axis y axis) 0mm x 0mm Identifier: 0x3d Timestamp: 584354 Subpixel: unknown Clones: CRTC: 0 CRTCs: 1 0 In my opinion, because the crtc is changed we need to redraw the screen, but actually the screen do not redraw, so I now is a little confused about the function of this command? what is the right behavior of the command? Thanks! Best Regards ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Kernel modesetting
Colin Guthrie wrote: 'Twas brillig, and Tino Keitel at 25/03/09 06:46 did gyre and gimble: 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. I think he knew that judging by what he wrote, but yes, randr 1.2/1.3 can do placement too. Just look at the output from xrandr command and the --help it provides :) Col Back to the original topic. I have 2.6.29 running but KMS always locks up the laptop when X starts. And 3D is horribly slow. While glxgears has sped up 2131 frames in 5.0 seconds = 426.172 FPS 2141 frames in 5.0 seconds = 428.160 FPS 2143 frames in 5.0 seconds = 428.454 FPS 2129 frames in 5.0 seconds = 425.781 FPS my real benchmark chromium B.S.U dropped from high 50's to 8FPS. Wow is back to unplayable and opengl still doesn't work. [I] x11-base/xorg-server (1.6.0...@25/03/09): X.Org X servers [I] media-libs/mesa (7.4_rc1...@25/03/09): OpenGL-like graphic library for Linux [I] x11-libs/libdrm (2@25/03/09): X.Org libdrm library [I] x11-drivers/xf86-input-evdev (2.2.0...@25/03/09): Generic Linux input driver [I] x11-drivers/xf86-input-synaptics (1@25/03/09): Driver for Synaptics touchpads [I] x11-drivers/xf86-video-intel (2.6.3...@25/03/09): X.Org driver for Intel cards Section Device Identifier intel Driver intel VendorName Intel Corporation BoardNameIntel Corporation Mobile 945GM/GMS/GME Express Integrated Graphics Controller # # Acceleration options Option FramebufferCompression true Option Tilingtrue Option DRI true Option XVideotrue #Option Legacy3D false Option TripleBuffer false Option AccelMethod UXA # XAA, EXA, UXA Option XvMC true # Other options OptionBackingStore true OptionPageFlip true EndSection # # Graphics support # CONFIG_AGP=m CONFIG_AGP_INTEL=m CONFIG_DRM=m CONFIG_DRM_I915=m CONFIG_VGASTATE=m CONFIG_VIDEO_OUTPUT_CONTROL=m CONFIG_FB=y CONFIG_FB_BOOT_VESA_SUPPORT=y CONFIG_FB_CFB_FILLRECT=y CONFIG_FB_CFB_COPYAREA=y CONFIG_FB_CFB_IMAGEBLIT=y CONFIG_FB_MODE_HELPERS=y CONFIG_FB_TILEBLITTING=y # # Frame buffer hardware drivers # CONFIG_FB_VGA16=m CONFIG_FB_VESA=y CONFIG_BACKLIGHT_LCD_SUPPORT=y CONFIG_LCD_CLASS_DEVICE=m CONFIG_LCD_PLATFORM=m CONFIG_BACKLIGHT_CLASS_DEVICE=m CONFIG_BACKLIGHT_PROGEAR=m # # Console display driver support # CONFIG_VGA_CONSOLE=y CONFIG_VGACON_SOFT_SCROLLBACK=y CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=256 CONFIG_DUMMY_CONSOLE=y CONFIG_LOGO=y CONFIG_LOGO_LINUX_CLUT224=y (sorry Colin, guess I missed reply all and hit reply) ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[RFC] glx: fix DRI2 memory leak
In trying to track down the memory leak in 20704, I found that the DRI2 drawable destroy routine doesn't seem to get called when new drawables are created and old ones destroyed (as in the glViewport case in the bug). The GLX core code takes care of destroying drawables correctly though, and even calls DestroyPixmap at the right time. However, DRI2 drawables have more state associated with them than just a single pixmap, so we have a __glXDRIdrawableDestroy function that takes care of that. However, by the time we get there, the GLX drawable is gone, so I never saw the if (drawable-pDraw != NULL) DRI2DestroyDrawable(drawable-pDraw); case get triggered... The simple patch below fixed that, but apparently isn't correct (see the bug report) since it causes crashes after a time. My patch was missing another change to set the private-count correctly in dri2GetBuffers though, which may be part of the fix as well. Has anyone else seen this leak? Anyone care to educate me a bit more about GLX drawable lifetime rules? Thanks, Jesse diff --git a/glx/glxext.c b/glx/glxext.c index c882372..73e5a9b 100644 --- a/glx/glxext.c +++ b/glx/glxext.c @@ -127,9 +127,9 @@ static Bool DrawableGone(__GLXdrawable *glxPriv, XID xid) break; } -glxPriv-pDraw = NULL; glxPriv-drawId = 0; __glXUnrefDrawable(glxPriv); +glxPriv-pDraw = NULL; return True; } ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
r200 exa performance regression in xserver-1.6?
Hi all. I've brought an old r200 card out of retirement to bring some bling to my work desktop. I was running xserver-1.5.something with an integrated nvidia card. I did an upgrade to xserver-1.6, mesa-7.4-rc1 and xf86-video-radeon-6.12.0. I don't have any figures for previous software on this hardware, but I can say that back when I was using this card at home on my old server, it used to *fly* - particularly after the exa-zero-copy-tfp landed. I certainly didn't get jumpiness or pauses like I'm getting now. So anyway, I'm running ecomorph ( compiz port for E17 ), and most of the effects are very slow and jumpy. I did a quick sysprof test while switching desktops, and it looks like it's all in memcpy: miClearToBackground 0.00 77.45 miPaintWindow 0.00 77.45 ValidateGC 0.00 77.45 In file /usr/bin/Xorg 0.00 77.45 In file /usr/lib/xorg/modules/libexa.so 0.00 77.45 exaPrepareAccessGC0.00 77.45 exaPrepareAccess0.00 77.45 exaPrepareAccessReg 0.00 77.45 exaDoMigration 0.00 77.45 In file /usr/lib/xorg/modules/libexa.so 0.00 77.45 memcpy 77.45 77.45 Full sysprof output: http://entropy.homelinux.org/r200_exa.sysprof X log: http://entropy.homelinux.org/Xorg.0.log I can do more extensive testing later. I suppose next is to actually go back to an earlier xserver and test, right? Dan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: r200 exa performance regression in xserver-1.6?
On 3/26/09, Daniel Kasak daniel.ka...@247realmedia.com wrote: Hi all. I've brought an old r200 card out of retirement to bring some bling to my work desktop. I was running xserver-1.5.something with an integrated nvidia card. I did an upgrade to xserver-1.6, mesa-7.4-rc1 and xf86-video-radeon-6.12.0. I don't have any figures for previous software on this hardware, but I can say that back when I was using this card at home on my old server, it used to *fly* - particularly after the exa-zero-copy-tfp landed. I certainly didn't get jumpiness or pauses like I'm getting now. So anyway, I'm running ecomorph ( compiz port for E17 ), and most of the effects are very slow and jumpy. Does adding a virtual line to the screen section of your config to limit the front buffer size help? Virtual 1280 1024 Alex ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: r200 exa performance regression in xserver-1.6?
On Thu, 2009-03-26 at 01:36 -0400, Alex Deucher wrote: On 3/26/09, Daniel Kasak daniel.ka...@247realmedia.com wrote: Hi all. I've brought an old r200 card out of retirement to bring some bling to my work desktop. I was running xserver-1.5.something with an integrated nvidia card. I did an upgrade to xserver-1.6, mesa-7.4-rc1 and xf86-video-radeon-6.12.0. I don't have any figures for previous software on this hardware, but I can say that back when I was using this card at home on my old server, it used to *fly* - particularly after the exa-zero-copy-tfp landed. I certainly didn't get jumpiness or pauses like I'm getting now. So anyway, I'm running ecomorph ( compiz port for E17 ), and most of the effects are very slow and jumpy. Does adding a virtual line to the screen section of your config to limit the front buffer size help? Virtual 1280 1024 Alex Hi Alex. Thanks for the quick response. Unfortunately, no that doesn't seem to affect it at all. xorg.conf which I forgot to attach last time: http://entropy.homelinux.org/xorg.conf Dan ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
