[ANNOUNCE] xf86-video-siliconmotion 1.7.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Xorg SiliconMotion Video Driver 1.7.0 features include support for SMI 50x chipsets, RandR 1.2, EXA acceleration Method, Dual Head, etc. Special thanks to Teddy Wang teddy.wang AT siliconmotion.com.cn for support and help in responding and/or triaging hardware related questions. ChangeLog: - Adam Jackson (1): Dead code removal. Arnaud Patard (1): Correct a problem when handling i420 format. Francisco Jerez (28): Memory detection moved before memory mapping in SMI_PreInit. Make the int10/VBE initialization depend on the UseBIOS configuration option. Updates in SMI_EnterVT when remapping memory. RandR rotation implemented. Some fixes in the EXA UTS/DTS code. Allow using XV and RandR rotation simultaneously. Fix XAA, ShadowFB and VT switching for non-sm501 chipsets RandR1.2 initial implementation (WIP) Some corrections in the CRTC code. Simple EXA Composite implementation. Changes in the video overlay clipping code. Lynx hardware cursor code adapted to the CRTC interfaces. Remove shadowfb based rotation support. Update the man page Remove unused fifo_* options. Disable screen centering on mode initialization. Some corrections on the Lynx modesetting code. Fix XAA SolidFill with 32 bpp framebuffer. Fall back to UseBIOS off when VBEInit fails. Enable linear memory mode on SMI_MapMmio. Fix crashes when switching VTs with EXA enabled. Add some quirks for SM712 modesetting. Cleanup the Lynx register saving/restoring code. Allocate crtc-funcs and output-funcs in the heap. Fix SMI_CrtcShadowAllocate. Add a CRTC/Output implementation using BIOS for modesetting. Add support for clone mode on Lynx chipsets. Some more quirks for the SM712. Nathael Pajani (1): Bit twelve on CPR00 bitfield is not bit eleven... Paulo Cesar Pereira de Andrade (92): Fix build for removal of xf86Version.h Add initial support and macros for the MSOC. Change SILICONMOTION_NAME value Add code to probe and recognize the SMI501 chipset MSOC doesn't access VGA registers or VBE/INT10 Update xaa and generic acceleration code for the MSOC. Update MSOC video interface. Bump version to 1.6.1. Split SMI_MapMem in SMI_MapMem and SMI_MapMmio Don't pretend this driver compiles on XFree86. Correct xv video problems on MSOC. Correct all compiler warning messages. Rename global smi501 functions to have SMI501 prefix. Complete rewrite of smi_501.c and smi_501.h. Update for new smi_501 interfaces. Correct video offscreen memory allocation routines. Add a missing CHECK_SECONDARY macro call. Add initial exa support for SMI501. Enable pci retry and pci burst by default. Add MSOC palette support to run at 8 bpp. Kludge to not lock the SMI 501 when running at 8bpp. Fix a leak and minor cosmetic change. Rework/simplify debug macros. Simplify hw cursor and sw cursor option handling. Remove unused .cvsignore files. Split SMI501_ModeInit in two functions. Correct logic in sw cursor handling and add missing entries to .gitignore. Correct problems in clock setting. Fix incorrect understanding of the pixel clock from specs. Don't try to find the closest clock, just use highest one. Properly check pScrn-driverPrivate before deferencing it. Don't always program CRT clock and registers. Update to match the SMI 502 chipset specs. Remove the macro field, and rename the detail structure to f. Correct clock programming for the SMI 501/502 Add support for the extra divider in the alternate pixel clock setting. Rewrite some macros to not have side effects in if/else nesting. Remove the IN_SEQ and OUT_SEQ macros. Rename macro bitfield to bits and correct a wrong division. Simplify regsmi.h by removing most unused SMI501 defines. Don't use the 1 multiplier on older chipsets. Rewrite WaitQueue and WaitIdle accell macros Make the input frequency in SMI501_FindPLLClock a variable Add a PanelSize/60Hz CVT mode at driver initialization Minor corrections for smi501 for the randr1.2 integration. Remove dependency on xf86cvt.c. Extra MSOC tweaks for the RandR1.2 changes. Correct incorrect pll3 calculation. Revert/modify some RandR changes to reenable XAA. Update sm502 pll3 programming. Don't change M1XCLK unless option specified in xorg.conf. Crt interface corrections. Use existing Dualhead option in MSOC. Make UseFBDev option functional again. Make Dualhead option functional. Update msoc to use randr cursor routines SMI501/502 cursor fixes.
Re: Xorg segfaults on XOpenDisplay multi thread
Hi Daniel, we are currently using Xorg 6.9(cannot change the version) we also have several pipes, meaning we need to open several displays. and of course we need to do it in threads. Do you have any suggestions? Daniel Stone wrote: On Mon, Dec 29, 2008 at 11:06:27AM +0200, Matan Drori wrote: I'm calling multiple XOpenDisplay calls from different threads. This is not really possible with Xlib. Should be okay with XCB, though. Cheers, Daniel ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver: Branch 'master'
Daniel Stone schrieb: xkb/xkbUtils.c | 17 - 1 file changed, 16 insertions(+), 1 deletion(-) New commits: commit 48dbaf173a82693fd72953983da9fc556cd1c6ed Author: Daniel Stone dan...@fooishbar.org Date: Tue Dec 30 12:17:14 2008 +1100 XKB: Also copy keyboard feedback when copying the keymap When updating the XKB keymap, make sure the keyboard feedback is also copied, to preserve autorepeat settings etc. Signed-off-by: Daniel Stone dan...@fooishbar.org Wasn't that commit meant for server-1.6-branch? Master worked fine before, and it was different anyway because of MPX, wasn't it? - Sascha signature.asc Description: OpenPGP digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver: Branch 'master'
'Twas brillig, and Sascha Hlusiak at 30/12/08 12:56 did gyre and gimble: Daniel Stone schrieb: xkb/xkbUtils.c | 17 - 1 file changed, 16 insertions(+), 1 deletion(-) New commits: commit 48dbaf173a82693fd72953983da9fc556cd1c6ed Author: Daniel Stone dan...@fooishbar.org Date: Tue Dec 30 12:17:14 2008 +1100 XKB: Also copy keyboard feedback when copying the keymap When updating the XKB keymap, make sure the keyboard feedback is also copied, to preserve autorepeat settings etc. Signed-off-by: Daniel Stone dan...@fooishbar.org Wasn't that commit meant for server-1.6-branch? Master worked fine before, and it was different anyway because of MPX, wasn't it? The details are on: http://bugs.freedesktop.org/show_bug.cgi?id=19048 Not sure if that helps tho' :) 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: xserver: Branch 'master'
On Tue, Dec 30, 2008 at 01:56:22PM +0100, Sascha Hlusiak wrote: Daniel Stone schrieb: commit 48dbaf173a82693fd72953983da9fc556cd1c6ed Author: Daniel Stone dan...@fooishbar.org Date: Tue Dec 30 12:17:14 2008 +1100 XKB: Also copy keyboard feedback when copying the keymap When updating the XKB keymap, make sure the keyboard feedback is also copied, to preserve autorepeat settings etc. Signed-off-by: Daniel Stone dan...@fooishbar.org Wasn't that commit meant for server-1.6-branch? Master worked fine before, and it was different anyway because of MPX, wasn't it? Yeesh. Keith, do you want to cherry-pick this to 1.6? Cheers, Daniel signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: bump: Xorg segfaults on XOpenDisplay multi thread
On Sunday 28 December 2008 08:56:50 Matan Drori wrote: Bump, adding some backtraces: Dump 1: #0 _X11TransWritev (ciptr=0x0, buf=0x21b96720, size=1) at ../../lib/xtrans/Xtrans.c:911 #1 0x20093910 in _XSendClientPrefix (dpy=value optimized out, client=value optimized out, auth_proto=0x0, auth_string=0x0, prefix=0x21b96784) at ConnDis.c:572 #2 0x200c4640 in XOpenDisplay (display=value optimized out) at OpenDis.c:295 #3 0x40001580 in ThreadMain_OpenDisplayAndStartTest (num=0x1) at ../../thread.cpp:37 #4 0x2027d5d0 in start_thread () from /lib/libpthread.so.0 #5 0x207cb730 in __clone2 () from /lib/libc.so.6.1 Dump 2: #0 0x2070f350 in malloc_consolidate () from /lib/libc.so.6.1 #1 0x20714830 in _int_malloc () from /lib/libc.so.6.1 #2 0x20716ef0 in calloc () from /lib/libc.so.6.1 #3 0x200c4530 in XOpenDisplay (display=value optimized out) at OpenDis.c:262 #4 0x40001580 in ThreadMain_OpenDisplayAndStartTest (num=0x2) at ../../thread.cpp:37 #5 0x2027d050 in start_thread () from /lib/libpthread.so.0 #6 0x207cb730 in __clone2 () from /lib/libc.so.6.1 i explored this topic for quite a while, when i debug it i see memory corruptions every time it crashes. memory corruptions doesn't always occur at the same place which makes it even harder and more confusing. Well, the ciptr=0x0 looks suspicious, to say the least. But it smells like you have an issue with thread safety somewhere underneath libX11, like in the C library. Did you link against libpthread? ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
xf86-video-savage: Document existence of IgnoreEDID option
This flag was added by me in a patch, but forgot to update the man page. This patch adds such update. Changelog: Document existence of IgnoreEDID option. -- perl -e '$x=2.4;print sprintf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);' From c67186bbb0070f53f2e801a71967f5482ae76789 Mon Sep 17 00:00:00 2001 From: =?utf-8?q?Alex=20Villac=C3=ADs=20Lasso?= a...@karlalex.palosanto.com Date: Sun, 28 Dec 2008 15:03:48 -0500 Subject: [PATCH] Document the existence of the IgnoreEDID option. --- man/savage.man |7 +++ 1 files changed, 7 insertions(+), 0 deletions(-) diff --git a/man/savage.man b/man/savage.man index e5d3d27..35528b2 100644 --- a/man/savage.man +++ b/man/savage.man @@ -139,6 +139,13 @@ driver use your mode line timing exactly, turn off the UseBios option. Use of the BIOS is required for dualhead operation. Default: on (use the BIOS). .TP +.BI Option \*qIgnoreEDID\*q \*q boolean \*q +Do not use EDID data for mode validation, but DDC is still used +for monitor detection. This is different from NoDDC option. +.br +The default value is +.B off. +.TP .BI Option \*qShadowStatus\*q \*q boolean \*q Enables the use of a shadow status register. There is a chip bug in the Savage graphics engine that can cause a bus lock when reading the engine -- 1.6.0.6 ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
xf86-video-savage: (1/2) YUV packed buffer and YV12 planar buffer (if required) are now separate allocations
This is a preparation for the next patch (placing XVideo YV12 data in
AGP memory). Currently a single buffer is allocated for YV12 planar data
and the YUY2 packed data that is the true format that the card can
display. This patch splits the buffers into two separate allocations,
and adds the capability to specify the offset of the planar data in
framebuffer memory.
Changelog:
* XVideo: Separate allocations of YV12 planar data and YUY2 packed data.
--
perl -e '$x=2.4;print sprintf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
From a2fb770cf0660c31d83fddd97f0c8b591b18586c Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Alex=20Villac=C3=ADs=20Lasso?= a...@karlalex.palosanto.com
Date: Sat, 27 Dec 2008 21:03:27 -0500
Subject: [PATCH] YUV packed buffer and YV12 planar buffer (if required) are now separate allocations.
BCI-mediated planar conversion can now use arbitrary offset in framebuffer as planar buffer, no longer restricted to space past packed buffer.
---
src/savage_video.c | 64 ++-
1 files changed, 47 insertions(+), 17 deletions(-)
diff --git a/src/savage_video.c b/src/savage_video.c
index 56ced56..c999b09 100644
--- a/src/savage_video.c
+++ b/src/savage_video.c
@@ -241,9 +241,11 @@ typedef struct {
Time freeTime;
int lastKnownPitch;
- int size;
- void *video_memory;
- int video_offset;
+ void *video_memory; /* opaque memory management information structure */
+ CARD32 video_offset; /* offset in video memory of packed YUV buffer */
+
+ void *video_planarmem; /* opaque memory management information structure */
+ CARD32 video_planarbuf; /* offset in video memory of planar YV12 buffer */
} SavagePortPrivRec, *SavagePortPrivPtr;
@@ -1041,6 +1043,10 @@ SavageStopVideo(ScrnInfoPtr pScrn, pointer data, Bool shutdown)
SavageFreeMemory(pScrn, pPriv-video_memory);
pPriv-video_memory = NULL;
}
+if (pPriv-video_planarmem != NULL) {
+ SavageFreeMemory(pScrn, pPriv-video_planarmem);
+ pPriv-video_planarmem = NULL;
+}
pPriv-videoStatus = 0;
} else {
if(pPriv-videoStatus CLIENT_VIDEO_ON) {
@@ -1170,19 +1176,18 @@ SavageCopyPlanarDataBCI(
unsigned char *srcV, /* V */
unsigned char *srcU, /* U */
unsigned char *dst,
+unsigned long planarOffset,
int srcPitch, int srcPitch2,
int dstPitch,
int h,int w)
{
SavagePtr psav = SAVPTR(pScrn);
-/* half of the dest buffer for copying the YVU data to it ??? */
-unsigned char *dstCopy = (unsigned char *)(((unsigned long)dst
-+ dstPitch * h
-+ 0x0f) ~0x0f);
+
/* for pixel transfer */
-unsigned long offsetY = (unsigned long)dstCopy - (unsigned long)psav-FBBase;
+unsigned long offsetY = planarOffset;
unsigned long offsetV = offsetY + srcPitch * h;
unsigned long offsetU = offsetV + srcPitch2 * (h1);
+unsigned char *dstCopy = (unsigned char *)psav-FBBase + planarOffset;
unsigned long dstOffset = (unsigned long)dst - (unsigned long)psav-FBBase;
int i;
@@ -1304,6 +1309,8 @@ SavageVideoSave(ScreenPtr pScreen, ExaOffscreenArea *area)
if (pPriv-video_memory == area)
pPriv-video_memory = NULL;
+if (pPriv-video_planarmem == area)
+pPriv-video_planarmem = NULL;
}
static CARD32
@@ -1870,6 +1877,7 @@ SavagePutImage(
unsigned char *dst_start;
int pitch, new_size, offset, offsetV=0, offsetU=0;
int srcPitch, srcPitch2=0, dstPitch;
+int planarFrameSize;
int top, left, npixels, nlines;
BoxRec dstBox;
CARD32 tmp;
@@ -1905,8 +1913,8 @@ SavagePutImage(
pitch = pScrn-bitsPerPixel * pScrn-displayWidth 3;
+/* All formats directly displayable by Savage are packed and 2 bytes per pixel */
dstPitch = ((width 1) + 15) ~15;
-/*new_h = ((dstPitch * height) + pitch - 1) / pitch;*/
new_size = dstPitch * height;
switch(id) {
@@ -1933,17 +1941,38 @@ SavagePutImage(
break;
}
+/* Calculate required memory for all planar frames */
+planarFrameSize = 0;
if (srcPitch2 != 0 S3_SAVAGE4_SERIES(psav-Chipset) psav-BCIforXv) {
-new_size = ((new_size + 0xF) ~0xF) + srcPitch * height + srcPitch2 * height;
+new_size = ((new_size + 0xF) ~0xF);
+planarFrameSize = srcPitch * height + srcPitch2 * height;
}
-/*if(!(pPriv-area = SavageAllocateMemory(pScrn, pPriv-area, new_h)))
- return BadAlloc;*/
-pPriv-video_offset = SavageAllocateMemory(pScrn, pPriv-video_memory,
- new_size);
+/* Buffer for final packed frame */
+pPriv-video_offset = SavageAllocateMemory(
+ pScrn, pPriv-video_memory,
+ new_size);
if (pPriv-video_offset == 0)
return BadAlloc;
+/* Packed format cases */
+if (planarFrameSize == 0) {
+ pPriv-video_planarbuf = 0;
+
+/* Planar format
xf86-video-savage: (2/2) Implement AGPforXv option
This patch adds the capability to place YV12 data in AGP memory while it
is being converted to packed YUY2. The single most expensive operation
in XVideo rendering on savage (on current implementation) is the upload
to the framebuffer. By placing YV12 data in an AGP buffer, the CPU saves
itself the work of going through the PCI bus. From benchmarks, this
method cuts the upload overhead by up to 25% compared to the
framebuffer-upload implementation. An option (AGPforXv) has been added
to enable this behavior conditionally (disabled by default). Please
review and comment on this.
Changelog:
* Allow YV12 planar data to reside in AGP memory
* Add AGPforXv switch for enabling/disabling implemented behavior
* Update manual to document AGPforXv switch
* Add explanation of limitations of BCI conversion
--
perl -e '$x=2.4;print sprintf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
diff --git a/man/savage.man b/man/savage.man
index 35528b2..9095b72 100644
--- a/man/savage.man
+++ b/man/savage.man
@@ -169,8 +169,26 @@ applies to Savage4 and newer chips. Default: \*qoff\*q (use COB).
.BI Option \*qBCIforXv\*q \*q boolean \*q
Use the BCI to copy and reformat Xv pixel data. Using the BCI for Xv causes
graphics artifacts on some chips. This option only applies to Savage4 and
-prosavage/twister chips. Default: on for prosavage and twister (use BCI for Xv);
-off for savage4 (do not use the BCI for Xv).
+prosavage/twister chips. On some combinations of chipsets and video players,
+BCI formatting might actually be slower than software formatting (\*qAGPforXv\*q
+might help in this case). BCI formatting can only be used on video data with
+a width that is a multiple of 16 pixels (which is the vast majority of videos).
+Other widths are handled through software formatting. Default: on for prosavage
+and twister (use BCI for Xv); off for savage4 (do not use the BCI for Xv).
+.TP
+.BI Option \*qAGPforXv\*q \*q boolean \*q
+Instructs the BCI Xv pixel formatter to use AGP memory as a scratch buffer.
+Ordinarily the BCI formatter uses a an area in framebuffer memory to hold
+YV12 planar data to be converted for display. This requires a somewhat expensive
+upload of YV12 data to framebuffer memory. The \*qAGPforXv\*q causes the BCI
+formatter to place the YV12 data in AGP memory instead, which can be uploaded
+faster than the framebuffer. Use of this option cuts upload overhead by 25%
+according to benchmarks. This option also smooths out most of the shearing
+present when using BCI for pixel conversion. Currently this option is
+.B experimental
+and is disabled by default. Video width restrictions that apply to \*qBCIforXv\*q
+also apply here. Only valid when \*qDRI\*q and \*qBCIforXv\*q are both active,
+and only on AGP chipsets. Default: \*qoff\*q.
.TP
.BI Option \*qAGPMode\*q \*q integer \*q
Set AGP data transfer rate.
diff --git a/src/savage_dri.c b/src/savage_dri.c
index 0d40222..216c915 100644
--- a/src/savage_dri.c
+++ b/src/savage_dri.c
@@ -520,6 +520,15 @@ static Bool SAVAGEDRIAgpInit(ScreenPtr pScreen)
}
}
+ if (psav-AGPforXv) {
+ pSAVAGEDRIServer-agpXVideo.offset = offset;
+ pSAVAGEDRIServer-agpXVideo.size = 2 * 1024 * 1024; /* Max XV image is 1024x1024x16bpp */
+ offset += pSAVAGEDRIServer-agpXVideo.size;
+ } else {
+ pSAVAGEDRIServer-agpXVideo.offset = 0;
+ pSAVAGEDRIServer-agpXVideo.size = 0;
+ }
+
pSAVAGEDRIServer-agpTextures.offset = offset;
pSAVAGEDRIServer-agpTextures.size = (pSAVAGEDRIServer-agp.size - offset);
@@ -581,6 +590,25 @@ static Bool SAVAGEDRIAgpInit(ScreenPtr pScreen)
}
}
+ /* XVideo buffer
+*/
+ if (pSAVAGEDRIServer-agpXVideo.size != 0) {
+ if ( drmAddMap( psav-drmFD,
+ pSAVAGEDRIServer-agpXVideo.offset,
+ pSAVAGEDRIServer-agpXVideo.size,
+ DRM_AGP, 0,
+ pSAVAGEDRIServer-agpXVideo.handle ) 0 ) {
+ xf86DrvMsg( pScreen-myNum, X_ERROR,
+ [agp] Could not add agpXVideo, will use framebuffer upload (slower) \n );
+ pSAVAGEDRIServer-agpXVideo.size = 0;
+ pSAVAGEDRIServer-agpXVideo.handle = 0;
+ } else {
+ xf86DrvMsg( pScreen-myNum, X_INFO,
+ [agp] agpXVideo handle = 0x%08lx\n,
+ pSAVAGEDRIServer-agpXVideo.handle );
+ }
+ }
+
/* AGP textures
*/
if ( drmAddMap( psav-drmFD,
@@ -1278,6 +1306,12 @@ void SAVAGEDRICloseScreen( ScreenPtr pScreen )
pSAVAGEDRIServer-aperture.map = NULL;
}
+ if ( pSAVAGEDRIServer-agpXVideo.map ) {
+ drmUnmap( pSAVAGEDRIServer-agpXVideo.map,
+pSAVAGEDRIServer-agpXVideo.size );
+ pSAVAGEDRIServer-agpXVideo.map = NULL;
+ }
+
if ( pSAVAGEDRIServer-agpTextures.map ) {
drmUnmap( pSAVAGEDRIServer-agpTextures.map,
pSAVAGEDRIServer-agpTextures.size );
@@ -1293,6 +1327,9 @@ void SAVAGEDRICloseScreen( ScreenPtr pScreen )
if (pSAVAGEDRIServer-aperture.handle)
drmRmMap(psav-drmFD,pSAVAGEDRIServer-registers.handle);
+ if
xf86-video-savage: EXA: use memcpy instead of loop for UploadToScreen operation
Optimization. Saves one compare per DWORD for common case where BCI
queue has ample space for bitmap data.
Changelog:
* EXA: use memcpy instead of loop for UploadToScreen operation
--
perl -e '$x=2.4;print sprintf(%.0f + %.0f = %.0f\n,$x,$x,$x+$x);'
From 70c9a579041f1ec588a580647966dff1e17e26d6 Mon Sep 17 00:00:00 2001
From: =?utf-8?q?Alex=20Villac=C3=ADs=20Lasso?= a...@karlalex.palosanto.com
Date: Tue, 30 Dec 2008 01:24:42 -0500
Subject: [PATCH] EXA: Optimization to use one memcpy per scanline instead of a conditional inside a loop for every dword.
---
src/savage_exa.c | 20 ++--
1 files changed, 14 insertions(+), 6 deletions(-)
diff --git a/src/savage_exa.c b/src/savage_exa.c
index 7c6efb3..538e000 100644
--- a/src/savage_exa.c
+++ b/src/savage_exa.c
@@ -495,13 +495,21 @@ SavageUploadToScreen(PixmapPtr pDst, int x, int y, int w, int h, char *src, int
dwords = (((w * Bpp) + 3) 2);
for (i = 0; i h; i++) {
srcp = (CARD32 *)src;
- for (j = 0; j dwords; j++) {
- if (queue 4) {
- BCI_RESET;
- queue = 120 * 1024;
+
+ if (4 * dwords = queue) {
+ /* WARNING: breaking BCI_PTR abstraction here */
+ memcpy(bci_ptr, srcp, 4 * dwords);
+ bci_ptr += dwords;
+ queue -= 4 * dwords;
+ } else {
+ for (j = 0; j dwords; j++) {
+ if (queue 4) {
+ BCI_RESET;
+ queue = 120 * 1024;
+ }
+ BCI_SEND(*srcp++);
+ queue -= 4;
}
- BCI_SEND(*srcp++);
- queue -= 4;
}
src += src_pitch;
}
--
1.6.0.6
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
ANN: xterm patch #238
Patch #238 - 2008/12/30 * update configure macro CF_XOPEN_SOURCE for AIX 6.x and Mint platforms. * reset the screen wrapping-flag at the end of ClearRight to fix an occasional case where the last character of a scrolled and wrapped line would be cleared (patch by Joe Peterson). * modify to use POSIX coding for comparing resource settings such as locale, to work with locales such as Turkish (report by M Vefa Bicakci). * turn on configure paste64 feature by default (request by Jean-Philippe Bernardy). It is runtime enabled/disabled with allowWindowOps. * turn on configure tcap-query feature by default, add resource allowTcapOps to make this runtime enabled/disabled. * make OSC 3 (change X property, from [242]patch #110) subject to allowWindowOps resource. * make VT220 DSR responses inactive in VT100-mode. * make DECUDK feature inactive in VT100-mode. * respond to incorrectly formatted DECRQSS with a cancel. * add allowFontOps resource to allow the fontsize-switching and font query/set control sequences to be enabled/disabled (prompted by Debian #510030). * some code cleanup based on gcc 4.x -Wconversion warnings in button.c and charproc.c * modify tcap-query feature to not return data for shifted cursor-keys when the keyboard type is set to vt220, since returning the same string for shifted/unshifted keys may confuse some applications (GenToo #212546). -- Thomas E. Dickey http://invisible-island.net ftp://invisible-island.net pgpXTpi3oSslD.pgp Description: PGP signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] Call xf86CrtcConfigInit() from within SavagePreInit(), fixes #19337
From: Frank de Lange freedeskto...@unternet.org
---
src/savage_driver.c | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/src/savage_driver.c b/src/savage_driver.c
index 919bd1a..1e93be0 100644
--- a/src/savage_driver.c
+++ b/src/savage_driver.c
@@ -49,6 +49,8 @@
#define DPMS_SERVER
#include X11/extensions/dpms.h
+#include xorg/xf86Crtc.h
+
#include xf86xv.h
#include savage_driver.h
@@ -80,6 +82,7 @@ static Bool SavagePciProbe(DriverPtr drv, int entity_num,
static Bool SavageProbe(DriverPtr drv, int flags);
static int LookupChipID(PciChipsets* pset, int ChipID);
#endif
+static void SavagePreInitCrtcConfig(ScrnInfoPtr pScrn);
static Bool SavagePreInit(ScrnInfoPtr pScrn, int flags);
static Bool SavageEnterVT(int scrnIndex, int flags);
@@ -1247,6 +1250,22 @@ static void SavageGetPanelInfo(ScrnInfoPtr pScrn)
}
}
+static Bool savage_xf86crtc_resize (ScrnInfoPtr scrn, int width, int height)
+{
+scrn-virtualX = width;
+scrn-virtualY = height;
+return TRUE;
+}
+
+static const xf86CrtcConfigFuncsRec savage_xf86crtc_config_funcs = {
+savage_xf86crtc_resize
+};
+
+static void SavagePreInitCrtcConfig(ScrnInfoPtr pScrn)
+{
+/* Allocate xf86CrtcConfig */
+xf86CrtcConfigInit (pScrn, savage_xf86crtc_config_funcs);
+}
static Bool SavagePreInit(ScrnInfoPtr pScrn, int flags)
{
@@ -3640,6 +3659,8 @@ static Bool SavageScreenInit(int scrnIndex, ScreenPtr
pScreen,
if (xf86DPMSInit(pScreen, SavageDPMS, 0) == FALSE)
xf86DrvMsg(pScrn-scrnIndex, X_ERROR, DPMS initialization failed\n);
+SavagePreInitCrtcConfig(pScrn);
+
#ifdef XF86DRI
if (psav-directRenderingEnabled) {
/* complete the DRI setup.*/
--
1.6.0.4
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Autorepeat question - quick review
Is this the right way to setup auto-repeating? I didn't see an
XkbSetRepeatRate or something similar... so is this what I should be
doing, or should I be calling something?
(note that this hunk is immediately after my call to
XkbInitKeyboardDeviceStruct(pDev, ...):
diff --git a/hw/xquartz/quartzKeyboard.c b/hw/xquartz/quartzKeyboard.c
index bc7efdf..2e8ca86 100644
--- a/hw/xquartz/quartzKeyboard.c
+++ b/hw/xquartz/quartzKeyboard.c
@@ -342,7 +342,12 @@ void DarwinKeyboardInit(DeviceIntPtr pDev) {
QuartzBell,
DarwinChangeKeyboardControl));
pthread_mutex_unlock(keyInfo_mutex);
- SwitchCoreKeyboard(pDev);
+// Enable autorepeat
+pDev-key-xkbInfo-desc-ctrls-repeat_delay = 500;
+pDev-key-xkbInfo-desc-ctrls-repeat_interval = 100;
+XkbSetRepeatKeys(pDev, -1, AutoRepeatModeOn);
+
+SwitchCoreKeyboard(pDev);
DarwinKeyboardSetDeviceKeyMap(keySyms);
}
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] Call xf86CrtcConfigInit() from within VIAPreInit()
From: Frank de Lange freedeskto...@unternet.org
I don't have a VIA-equipped machine so I can not test this patch but given that
VIA and Savage are 'quite similar' this should work to fix the segfault on
start caused by use of an unallocated xf86CrtcConfig as well...
If someone with access to a VIA-equipped machine can test this... it might make
some VIA users happy...
PS for me the current VIA driver does not even compile - unrelated to this
patch - so even if I had a machine I'd have been unable to test...
Cheers//Frank
---
src/via_driver.c | 21 +
1 files changed, 21 insertions(+), 0 deletions(-)
diff --git a/src/via_driver.c b/src/via_driver.c
index c2312a8..337f597 100644
--- a/src/via_driver.c
+++ b/src/via_driver.c
@@ -41,6 +41,7 @@
#define DPMS_SERVER
#include X11/extensions/dpms.h
+#include xorg/xf86Crtc.h
#include via_driver.h
#include via_video.h
@@ -59,6 +60,7 @@
static void VIAIdentify(int flags);
static Bool VIAProbe(DriverPtr drv, int flags);
+static void VIAPreInitCrtcConfig(ScrnInfoPtr pScrn);
static Bool VIAPreInit(ScrnInfoPtr pScrn, int flags);
static Bool VIAEnterVT(int scrnIndex, int flags);
static void VIALeaveVT(int scrnIndex, int flags);
@@ -622,6 +624,23 @@ VIAProbeDDC(ScrnInfoPtr pScrn, int index)
}
}
+static Bool via_xf86crtc_resize (ScrnInfoPtr scrn, int width, int height)
+{
+scrn-virtualX = width;
+scrn-virtualY = height;
+return TRUE;
+}
+
+static const xf86CrtcConfigFuncsRec via_xf86crtc_config_funcs = {
+via_xf86crtc_resize
+};
+
+static void VIAPreInitCrtcConfig(ScrnInfoPtr pScrn)
+{
+/* Allocate xf86CrtcConfig */
+xf86CrtcConfigInit (pScrn, via_xf86crtc_config_funcs);
+}
+
static Bool VIAPreInit(ScrnInfoPtr pScrn, int flags)
{
EntityInfoPtr pEnt;
@@ -2066,6 +2085,8 @@ VIAScreenInit(int scrnIndex, ScreenPtr pScreen, int argc,
char **argv)
DEBUG(xf86DrvMsg(pScrn-scrnIndex, X_INFO, - Color maps etc. set up\n));
pVia-agpDMA = FALSE;
+VIAPreInitCrtcConfig(pScrn);
+
#ifdef XF86DRI
if (pVia-directRenderingEnabled)
pVia-directRenderingEnabled = VIADRIFinishScreenInit(pScreen);
--
1.6.0.4
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] Call xf86CrtcConfigInit() from within VIAPreInit()
On Tue, 30 Dec 2008, frankdelange wrote: From: Frank de Lange freedeskto...@unternet.org I don't have a VIA-equipped machine so I can not test this patch but given that VIA and Savage are 'quite similar' this should work to fix the segfault on start caused by use of an unallocated xf86CrtcConfig as well... If someone with access to a VIA-equipped machine can test this... it might make some VIA users happy... PS for me the current VIA driver does not even compile - unrelated to this patch - so even if I had a machine I'd have been unable to test... The VIA driver is pretty much deprecated, use openchrome instead. t ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH] Call xf86CrtcConfigInit() from within VIAPreInit()
On Tue, Dec 30, 2008 at 5:08 PM, frankdelange fr...@ostrogoth.unternet.org wrote: From: Frank de Lange freedeskto...@unternet.org I don't have a VIA-equipped machine so I can not test this patch but given that VIA and Savage are 'quite similar' this should work to fix the segfault on start caused by use of an unallocated xf86CrtcConfig as well... It looks to me like all non-randr 1.2 capable drivers need this fix. I think the proper fix is to find out what changed in the xserver that makes this change necessary and fix that. Alex ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
(trivia) XCB kitten logo?
A completely trivial question: what's the origin of the XCB logo, the kitten with the big feet? - d. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [radeonhd] Initial Radeon R6xx/R7xx acceleration support pushed
On Tue, Dec 30, 2008 at 8:39 PM, Nigel Rantor wig...@wiggly.org wrote: Alex Deucher wrote: It's finally here! r6xx-r7xx-support branches of the drm and xf86-video-radeonhd. http://cgit.freedesktop.org/mesa/drm/log/?h=r6xx-r7xx-support http://cgit.freedesktop.org/xorg/driver/xf86-video-radeonhd/log/?h=r6xx-r7xx-support After months of hard work we are finally able to push out initial drm and accel code for r6xx and r7xx chipsets. We couldn't have done this without a lot of hard work from a lot of people. Of particular note: Matthias Hopf - implementing r600_demo as a test program to get the hw up and running Dave Airlie - initial r6xx drm implementation John Bridgman - sheparding along the IP review process This release is mostly targeted at developers as the code is not really ready for regular use. The accompanying r6xx/r7xx register spec is still in IP review and will be released soon. Yay! Exciting! Congrats and thanks to everyone who made this possible. I'm a dev by trade and I'd be quite happy to test it on my system (R770) and provide reports, or would you only recommend this for people who actually want to hack on it? It's not particularly useful for end users at the moment. Alex ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: (trivia) XCB kitten logo?
Not that I have any background on the subject, but clicking on the logo pulled up this page: http://xcb.freedesktop.org/KittyLogo/ Apparently someone with a webcomic donated their character as a mascot. -- William Tracy afishion...@gmail.com -- wtr...@calpoly.edu Vice President, Cal Poly Linux Users' Group http://www.cplug.org I disapprove of what you say, but I will defend to the death your right to say it. -- Evelyn Beatrice Hall, frequently mis-attributed to Voltaire ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: bump: Xorg segfaults on XOpenDisplay multi thread
hi bill
i went to that direction, i linked to libpthread didn't do any good
i tried working with ptmalloc3 instead of the ptmalloc2 thats in glibc,
and it didn't do any good so i went back one layer up to the Xorg
I did that since i couldn't re produce bug by linking malloc debuggers
to my programs(tried dmalloc and Electric fence)
but it seems like it doesn't reproduce just cause the malloc debugger
has different timings.
i agree that the ciptr=0x0 is very suspicious, after looking further
into it (Xorg debug without -o2) i saw that it goes a bit up.
looks like there is no connection with the server, or maybe its just a
memory override somewhere along the way.
couldn't quite pin point the spot.
and it couldn't be that the dpy-trans_conn got a wrong value when
connected because if so the it would have returned null after the call
for _X11TransConnectDisplay
*OpenDis.c:154*
if ((dpy-trans_conn = _X11TransConnectDisplay (
display_name, fullname, idisplay,
iscreen, conn_auth_name,
conn_auth_namelen,
conn_auth_data,
conn_auth_datalen)) == NULL) {
Xfree ((char *) dpy);
return(NULL);
}
(dpy-trans_conn is what we later send as the ciptr...)
I also added a print for all the data sent in this function and it
always prints the correct information, even when sagfaults.
if you look at the second segfualt its in a very simple line
*OpenDis.c:262*
if ((dpy-bufptr = dpy-buffer = Xcalloc(1, conn_buf_size)) == NULL)
just a simple calloc(buffer size correct, always), and that really
puzzled me... but i guess its just something corrupted in the memory.
any thing else you think might lead this?
Bill Crawford wrote:
On Sunday 28 December 2008 08:56:50 Matan Drori wrote:
Bump, adding some backtraces:
Dump 1:
#0 _X11TransWritev (ciptr=0x0, buf=0x21b96720, size=1) at
../../lib/xtrans/Xtrans.c:911
#1 0x20093910 in _XSendClientPrefix (dpy=value optimized out,
client=value optimized out, auth_proto=0x0, auth_string=0x0,
prefix=0x21b96784) at ConnDis.c:572
#2 0x200c4640 in XOpenDisplay (display=value optimized out)
at OpenDis.c:295
#3 0x40001580 in ThreadMain_OpenDisplayAndStartTest (num=0x1)
at ../../thread.cpp:37
#4 0x2027d5d0 in start_thread () from /lib/libpthread.so.0
#5 0x207cb730 in __clone2 () from /lib/libc.so.6.1
Dump 2:
#0 0x2070f350 in malloc_consolidate () from /lib/libc.so.6.1
#1 0x20714830 in _int_malloc () from /lib/libc.so.6.1
#2 0x20716ef0 in calloc () from /lib/libc.so.6.1
#3 0x200c4530 in XOpenDisplay (display=value optimized out)
at OpenDis.c:262
#4 0x40001580 in ThreadMain_OpenDisplayAndStartTest (num=0x2)
at ../../thread.cpp:37
#5 0x2027d050 in start_thread () from /lib/libpthread.so.0
#6 0x207cb730 in __clone2 () from /lib/libc.so.6.1
i explored this topic for quite a while, when i debug it i see memory
corruptions every time it crashes. memory corruptions doesn't always occur
at the same place which makes it even harder and more confusing.
Well, the ciptr=0x0 looks suspicious, to say the least. But it smells like
you
have an issue with thread safety somewhere underneath libX11, like in the C
library. Did you link against libpthread?
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
RE: gma950 + latest x11 + latest intel driver
Vasily Khoruzhick wrote on Monday, December 29, 2008 11:52 PM: On 29 December 2008 15:53:27 Jin, Gordon wrote: Vasily Khoruzhick wrote on Monday, December 29, 2008 12:32 AM: Hi, I'm testing latest x11 from git (gentoo's x11 overlay) and latest intel driver from git (videocard: gma950). Here's some results: 0. xf86-video-intel-2.5.1 + xorg-server-1.5.3 + mesa-7.2 + kernel 2.6.28: 3D is not usable, ~3-5 fps in quake3. 2D is stable and fast 1. Latest x11 stack from git + latest xf86-video-intel from git + kernel 2.6.28 + exa (no dri2): 3D is not usable, ~5-10 fps in quake3. 2D is stable and fast Did you try mesa git? Gordon Yep, forgot to mention it. On my 945gm, quake3 shows ~60 fps with mesa git, and 90-100 fps if setting vblank_mode=0. Can you check if glxinfo shows direct rendering: Yes and OpenGL renderer string shows Intel? Gordon ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: evdev keyboard problem in xorg 1.5.2 and evdev 2.0.99+
On Tue, 30 Dec 2008, Scott Serr wrote: I'm using Ubuntu 8.10 / Intrepid. I'm working on a multiseat project, but this is not a multiseat issue. I disable HAL, to let X handle the input devices: Section ServerFlags Option AutoAddDevices false EndSection Then specify my keyboard: Section InputDevice Identifier Keyboard0 Driver evdev Option Device /dev/input/event1 Option CoreKeyboard Option XkbRulesxorg Option XkbModelevdev Option XkbLayout us EndSection This works correctly, I'm able to type with my first keyboard and the second one is not listened to. This is good. The problem is keys are mapped weird. up arrow launches the ScreenShot tool in Gnome. Gnome keyboard is set to evdev managed. It seems I can't give it any Xkb options to resolve this. XkbRules needs to be evdev, not model. t ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
