Re: Xorg segfaults on XOpenDisplay multi thread
Matan Drori ma...@graphtech.co.il writes: Machine spec: IA64 /SUSE Linux Enterprise Server/ 10 sp 2 xorg x11 6.9.0-50.58 I have a very simple test program that opens 4 threads and does XOpenDisplay(opening 4 separate display objects). i keep getting segfaults on different places in the function seems like some kind timing problem that causes memory corruption. You have called XInitThreads? (See man XInitThreads) (I don't know how thread-safe xorg is. I have the impression that there are some issues. But without XInitThreads(), it isn't supposed to be thread-safe). eirik ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH 1/6] Includes some new structures and defined MACRO in edid.h
On Wed, 2008-12-24 at 21:29 +0800, Wu, Fengguang wrote:
On Sat, Dec 20, 2008 at 04:34:27AM +0200, Ma, Ling wrote:
defined corresponding structure and MACRO for detailed timing operation
---
hw/xfree86/ddc/edid.h | 73
+
1 files changed, 73 insertions(+), 0 deletions(-)
diff --git a/hw/xfree86/ddc/edid.h b/hw/xfree86/ddc/edid.h
index 31bc7c1..8751107 100644
--- a/hw/xfree86/ddc/edid.h
+++ b/hw/xfree86/ddc/edid.h
@@ -553,4 +553,77 @@ typedef struct {
extern _X_EXPORT xf86MonPtr ConfiguredMonitor;
+#define CEA_EXT 0x02
+#define VTB_EXT 0x10
+#define DI_EXT0x40
+#define LS_EXT0x50
+#define MI_EXT0x60
+
+#define CEA_EXT_MIN_DATA_OFFSET 4
+#define CEA_EXT_MAX_DATA_OFFSET 127
+#define CEA_EXT_DET_TIMING_NUM 6
+
+#define EXT_TAG 0
+#define EXT_REV 1
+
+struct cea_video_blk {
+ Uchar video_code;
+};
+
+struct cea_audio_blk {
+Uchar descs[3];
Inconsistent indents.
fixed
+};
+
+struct hdmi {
Name too short?
fixed
+ Uchar support_flags;
+ Uchar max_tmds_clock;
+ Uchar latency_present;
+ Uchar video_latency;
+ Uchar audio_latency;
+ Uchar interlaced_video_latency;
+ Uchar interlaced_audio_latency;
+};
+
+struct cea_vendor_blk {
+ unsigned char ieee_id[3];
+ Uchar port_addr[2];
Inconsistent types.
+ struct hdmi hdmi;
+};
+
+struct cea_speaker_blk
+{
+ Uchar FLR:1;
+ Uchar LFE:1;
+ Uchar FC:1;
+ Uchar RLR:1;
+ Uchar RC:1;
+ Uchar FLRC:1;
+ Uchar RLRC:1;
+ Uchar FLRW:1;
+ Uchar FLRH:1;
+ Uchar TC:1;
+ Uchar FCH:1;
+ Uchar Resv:5;
+ Uchar ResvByte;
+};
+
+struct cea_data_blk {
+ Uchar len:5;
+ Uchar tag:3;
+union{
+struct cea_video_blk video;
+struct cea_audio_blk audio;
+struct cea_vendor_blk vendor;
+struct cea_speaker_blk speaker;
+ }u;
More indents, please.
fixed
+};
+
+struct cea_ext_body {
+ Uchar tag;
+ Uchar rev;
+ Uchar dt_offset;
+ Uchar flags;
+ struct cea_data_blk data_collection;
+};
+
#endif /* _EDID_H_ */
--
1.5.4.4
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [PATCH 3/6] handle detailed timing operation in xf86EdidModes.c
On Thu, 2008-12-25 at 10:23 +0800, Wu, Fengguang wrote:
On Sat, Dec 20, 2008 at 04:37:51AM +0200, Ma, Ling wrote:
handled detailed timing operation .e.g extract detailed timing modes from
EDID and cea ext,
then insert mode list.
---
hw/xfree86/ddc/xf86DDC.h | 44 ++
hw/xfree86/modes/xf86EdidModes.c | 278
--
2 files changed, 189 insertions(+), 133 deletions(-)
diff --git a/hw/xfree86/ddc/xf86DDC.h b/hw/xfree86/ddc/xf86DDC.h
index 07411b8..0f4f65f 100644
--- a/hw/xfree86/ddc/xf86DDC.h
+++ b/hw/xfree86/ddc/xf86DDC.h
@@ -62,4 +62,48 @@ extern _X_EXPORT DisplayModePtr xf86DDCGetModes(int
scrnIndex, xf86MonPtr DDC);
extern _X_EXPORT Bool
xf86MonitorIsHDMI(xf86MonPtr mon);
+/*
+ * Quirks to work around broken EDID data from various monitors.
+ */
+typedef enum {
+DDC_QUIRK_NONE = 0,
+/* First detailed mode is bogus, prefer largest mode at 60hz */
+DDC_QUIRK_PREFER_LARGE_60 = 1 0,
+/* 135MHz clock is too high, drop a bit */
+DDC_QUIRK_135_CLOCK_TOO_HIGH = 1 1,
+/* Prefer the largest mode at 75 Hz */
+DDC_QUIRK_PREFER_LARGE_75 = 1 2,
+/* Convert detailed timing's horizontal from units of cm to mm */
+DDC_QUIRK_DETAILED_H_IN_CM = 1 3,
+/* Convert detailed timing's vertical from units of cm to mm */
+DDC_QUIRK_DETAILED_V_IN_CM = 1 4,
+/* Detailed timing descriptors have bogus size values, so just take the
+ * maximum size and use that.
+ */
+DDC_QUIRK_DETAILED_USE_MAXIMUM_SIZE = 1 5,
+/* Monitor forgot to set the first detailed is preferred bit. */
+DDC_QUIRK_FIRST_DETAILED_PREFERRED = 1 6,
+/* use +hsync +vsync for detailed mode */
+DDC_QUIRK_DETAILED_SYNC_PP = 1 7,
+/* Force single-link DVI bandwidth limit */
+DDC_QUIRK_DVI_SINGLE_LINK = 1 8,
+} ddc_quirk_t;
+
+DisplayModePtr xf86DDCGetModes(int scrnIndex, xf86MonPtr DDC);
+
+extern Bool
+xf86MonitorIsHDMI(xf86MonPtr mon);
+
+typedef void (* handle_detailed_fn)(struct detailed_monitor_section *,void
*);
+
+void xf86ForEachDetailedBlock(xf86MonPtr mon,
+ handle_detailed_fn,
+ void *data);
+
+ddc_quirk_t
+xf86DDCDetectQuirks(int scrnIndex, xf86MonPtr DDC, Bool verbose);
+
+void xf86DetTimingApplyQuirks(struct detailed_monitor_section *det_mon,
+ ddc_quirk_t quirks, int hsize, int vsize);
+
#endif
diff --git a/hw/xfree86/modes/xf86EdidModes.c
b/hw/xfree86/modes/xf86EdidModes.c
index 1413e87..e016e43 100644
--- a/hw/xfree86/modes/xf86EdidModes.c
+++ b/hw/xfree86/modes/xf86EdidModes.c
@@ -45,20 +45,24 @@
#include string.h
#include math.h
+void static handle_detailed_rblank(struct detailed_monitor_section
*det_mon,
static void
fixed
+ void *data)
+{
+
extra blank line
fixed
+if (det_mon-type == DS_RANGES)
+if (det_mon-section.ranges.supported_blanking CVT_REDUCED)
+*(Bool*)data = TRUE;
+}
+
static Bool
xf86MonitorSupportsReducedBlanking(xf86MonPtr DDC)
{
/* EDID 1.4 explicitly defines RB support */
if (DDC-ver.revision = 4) {
- int i;
- for (i = 0; i DET_TIMINGS; i++) {
- struct detailed_monitor_section *det_mon = DDC-det_mon[i];
- if (det_mon-type == DS_RANGES)
- if (det_mon-section.ranges.supported_blanking
CVT_REDUCED)
- return TRUE;
- }
-
- return FALSE;
+Bool ret = FALSE;
+
+xf86ForEachDetailedBlock(DDC, handle_detailed_rblank, ret);
+return ret;
}
/* For anything older, assume digital means RB support. Boo. */
@@ -68,34 +72,6 @@ xf86MonitorSupportsReducedBlanking(xf86MonPtr DDC)
return FALSE;
}
-/*
- * Quirks to work around broken EDID data from various monitors.
- */
-
-typedef enum {
-DDC_QUIRK_NONE = 0,
-/* First detailed mode is bogus, prefer largest mode at 60hz */
-DDC_QUIRK_PREFER_LARGE_60 = 1 0,
-/* 135MHz clock is too high, drop a bit */
-DDC_QUIRK_135_CLOCK_TOO_HIGH = 1 1,
-/* Prefer the largest mode at 75 Hz */
-DDC_QUIRK_PREFER_LARGE_75 = 1 2,
-/* Convert detailed timing's horizontal from units of cm to mm */
-DDC_QUIRK_DETAILED_H_IN_CM = 1 3,
-/* Convert detailed timing's vertical from units of cm to mm */
-DDC_QUIRK_DETAILED_V_IN_CM = 1 4,
-/* Detailed timing descriptors have bogus size values, so just take the
- * maximum size and use that.
- */
-DDC_QUIRK_DETAILED_USE_MAXIMUM_SIZE = 1 5,
-/* Monitor forgot to set the first detailed is preferred bit. */
-DDC_QUIRK_FIRST_DETAILED_PREFERRED = 1 6,
-/* use +hsync +vsync for detailed mode */
-DDC_QUIRK_DETAILED_SYNC_PP
Re: Xorg segfaults on XOpenDisplay multi thread
I'm Using XInitThreads(), and have no use for the other thread functions since im not sharing a display(XLockDisplay and XUnlockDisplay that recive a display object). I'm calling multiple XOpenDisplay calls from different threads. It looks like a deeper issue since I'm not sharing the display object itself. if needed i can post my test program here(very small) even tough i couldn't re produce it on my openSuse 11.1 machine, only on the IA64 sles 10 sp 2 machine. Eirik Byrkjeflot Anonsen wrote: Matan Drori ma...@graphtech.co.il writes: Machine spec: IA64 /SUSE Linux Enterprise Server/ 10 sp 2 xorg x11 6.9.0-50.58 I have a very simple test program that opens 4 threads and does XOpenDisplay(opening 4 separate display objects). i keep getting segfaults on different places in the function seems like some kind timing problem that causes memory corruption. You have called XInitThreads? (See man XInitThreads) (I don't know how thread-safe xorg is. I have the impression that there are some issues. But without XInitThreads(), it isn't supposed to be thread-safe). eirik ___ 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 1.6 branch and mouse position zapping
'Twas brillig, and Colin Guthrie at 29/12/08 09:31 did gyre and gimble: 'Twas brillig, and Colin Guthrie at 26/12/08 15:25 did gyre and gimble: 'Twas brillig, and Peter Hutterer at 26/12/08 00:25 did gyre and gimble: On Wed, Dec 24, 2008 at 11:41:10AM +, Colin Guthrie wrote: Just built the 1.6 branch + recent mesa snapshot and other such stuff. It seems to be stable enough just now, but one thing that's been affected is how the mouse positions itself to top-left after a certain operations. So far I've found odd behaviour when doing: * Compiz cube dragging (ctrl+alt+click and drag) * Compiz window moving (alt+click and drag) * Compiz window moving (click and drag on title bar) When this happens the mouse just jumps to the top left, but not always immediately. While this could easily be a compiz issue (I certainly cannot reproduce in metacity), I'm guessing it's related to the xserver change. I have also updated to the latest input-proto and other such stuff too. Is there an obvious starting point to look further into this? Or perhaps it's a known issue? can you reproduce this with any other client too? It's most likely an X server issue, but a good reproduceable behaviour in a client other than compiz makes it easier for me to find the bug. My first guess is that event replay after synchronous grabs have the wrong coordinates. You say it doesn't always happen immediately: try to move particularly fast or slow to see if that can trigger it. It's really hard to describe! Speed of movement doesn't seem to make much odds but I have narrowed down the behaviour to the Snapping Windows compiz plugin. Disabling this makes things a lot more stable but there are still some issues. Every time I move the cube face, either with a window drag to the edge, or with a keystroke, the mouse pointer zaps to the top left. I can't duplicate the behaviour in metacity, but I've not tried in Kwin4 yet. I'm not 100% certain it's a xserver issue here and perhaps compiz is hooking into something it shouldn't be, but it's certainly a regression of sorts. Not really sure how to give you better info to help diagnose :( I'll try asking on compiz IRC to see if anyone else is experiencing the same issues. OK, some strange things happened. I applied the patch for the locale/layout settings http://bugs.freedesktop.org/show_bug.cgi?id=19048 and now things work fine :s There have been other changes on my system but nothing that would jump out at me as being overly relevant. If I have time, I'll go back to a server without this patch and see if the problem returns. I have also updated libcompizconfig which was updated on the 26th December to a buggy build, but as I originally noticed this behaviour on the 24th December, I doubt this is actually relevant! Tell a lie. It seems I built the xserver against an older x11-proto-devel that did not have the latest dri2proto.. Not sure it will matter but will rebuild and see what happens :) 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 1.6 branch and mouse position zapping
'Twas brillig, and Colin Guthrie at 29/12/08 09:42 did gyre and gimble: OK, some strange things happened. I applied the patch for the locale/layout settings http://bugs.freedesktop.org/show_bug.cgi?id=19048 and now things work fine :s There have been other changes on my system but nothing that would jump out at me as being overly relevant. If I have time, I'll go back to a server without this patch and see if the problem returns. I have also updated libcompizconfig which was updated on the 26th December to a buggy build, but as I originally noticed this behaviour on the 24th December, I doubt this is actually relevant! Tell a lie. It seems I built the xserver against an older x11-proto-devel that did not have the latest dri2proto.. Not sure it will matter but will rebuild and see what happens :) Well I rebuilt with newer dri2proto and as expected nothing changed. Also tried disabling the last patch for locale settings etc. and it made no odds either. Rebuilding libcompizconfig seems to have been the key here. Anyways, it's certainly not a problem in the xserver so not and issue for 1.6 :) Cheers for the help. 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: Xorg segfaults on XOpenDisplay multi thread
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 signature.asc Description: Digital signature ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [RFC] RandR 1.3 properties, version 2
On Dec 19, 08 12:23:20 +1100, Graeme Gill wrote: Matthias Hopf wrote: I have just pushed a change to radeonhd, that implements the mandatory bits of RandR 1.3 output properties, which can thus be seen as a reference implementation. Sorry I guess I'm not following very well :- so this means that the XRandR EDID_DATA atom now becomes what ? Just EDID Reason was that people objected to all caps properties, and EDIDData looked awkward to me (and EdidData would be plainly wrong, because EDID is an abbreviation). CU Matthias -- Matthias Hopf mh...@suse.de ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R D www.mshopf.de ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xrandr: needs changes for dualhead + panning
On Dec 19, 08 20:50:29 +0100, Maarten Maathuis wrote: On 12/19/2008 08:42 PM, Carl Karsten wrote: Maarten Maathuis wrote: The placement logic is output driven, and doesn't take panning into account. So you end up with strange overlap. If dual head + panning was a goal you might consider fixing this. It doesn't seem trivial to do from a quick look. On the plus side it's just a xrandr change. You're right, forgot about that. Have to think about it. It's not really complicated, but you have to think about how to specify the type of panning as in: dual head + panning could mean a the whole space pans when you get to the side of the virtual space, b pan each physical display separately, c a combination of a/b. Good point. (a) would need changes on the protocol side (imo) Probably not on the protocol side, but maybe in the xserver implementation. OTOH it might already be possible to specify this with borders. Again, have to think about it :^) I was thinking of (b). CU Matthias -- Matthias Hopf mh...@suse.de ____ __ Maxfeldstr. 5 / 90409 Nuernberg (_ | | (_ |__ m...@mshopf.de Phone +49-911-74053-715 __) |_| __) |__ R D www.mshopf.de ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: gma950 + latest x11 + latest intel driver
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. signature.asc Description: This is a digitally signed message part. ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Current tinderbox regression (libGL)
http://tinderbox.x.org/builds/2008-12-28-0008/ http://tinderbox.x.org/builds/2008-12-28-0008/logs/libGL/#build r300_render.c: In function 'r300FireEB': r300_render.c:213: error: expected ';' before 'do' http://cgit.freedesktop.org/mesa/mesa/commit/?id=0d1f90c75e39191f1824b382dfb8d709a3e70d01 -- Chris Ball c...@laptop.org ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Initial Radeon R6xx/R7xx acceleration support pushed
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. Current drm status: - only indirect ioctl currently implemented (for EXA/Xv) - mesa support will require additional work Current EXA/Xv status: - lack of direction blitter makes overlapping copy blits difficult. current code breaks down overlapping blits into line by line blits of non-overlapping regions. running xcompmgr -a is highly recommended for decent performance - a8 support has issues - planar Xv shader implemented, but not working properly yet - missing Xv shader support for packed formats. should be easy to adapt the planar Xv shader once that is working - composite mask support is currently broken. I suspect the interpolater setup. - depth 16 is untested Alex ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[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: Initial Radeon R6xx/R7xx acceleration support pushed
Just to clarify for those that want to play with this, you'll need to build the r6xx-r7xx-support branches of the drm and radeonhd. The drm is also required for r600_demo. Alex On Mon, Dec 29, 2008 at 4:33 PM, Alex Deucher alexdeuc...@gmail.com 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. Current drm status: - only indirect ioctl currently implemented (for EXA/Xv) - mesa support will require additional work Current EXA/Xv status: - lack of direction blitter makes overlapping copy blits difficult. current code breaks down overlapping blits into line by line blits of non-overlapping regions. running xcompmgr -a is highly recommended for decent performance - a8 support has issues - planar Xv shader implemented, but not working properly yet - missing Xv shader support for packed formats. should be easy to adapt the planar Xv shader once that is working - composite mask support is currently broken. I suspect the interpolater setup. - depth 16 is untested Alex ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
gimp is able to kill Xserver with Intel driver
Hello, using gimp, I'm able to reproduce the following segfault of the xserver: Core was generated by `/usr/bin/X11/X -nolisten tcp'. Program terminated with signal 11, Segmentation fault. [New process 4181] #0 0x00433d32 in dixLookupPrivate (privates=0x1d386c0, key=0x7da880) at ../../dix/privates.c:79 79 ../../dix/privates.c: No such file or directory. in ../../dix/privates.c (gdb) where #0 0x00433d32 in dixLookupPrivate (privates=0x1d386c0, key=0x7da880) at ../../dix/privates.c:79 #1 0x004cf2b4 in miDCPutUpCursor (pDev=0xc65d60, pScreen=0x9d0340, pCursor=0x2a903290001, x=-42829, y=-26929, source=0, mask=16777215) at ../../mi/midispcur.c:449 #2 0x004def6e in miSpriteRestoreCursor (pDev=0xc65d60, pScreen=0x9d0340) at ../../mi/misprite.c:1025 #3 0x004df4a6 in miSpriteBlockHandler (i=value optimized out, blockData=0x0, pTimeout=0x0, pReadmask=0x1) at ../../mi/misprite.c:525 #4 0x7f3e6a83aae7 in I830BlockHandler (i=value optimized out, blockData=0x0, pTimeout=0x7fff762f9d28, pReadmask=0x58b3) at i830_driver.c:2632 #5 0x00533ba8 in AnimCurScreenBlockHandler (screenNum=0, blockData=0x0, pTimeout=0x7fff762f9d28, pReadmask=0x7daca0) at ../../render/animcur.c:222 #6 0x004febce in compBlockHandler (i=0, blockData=0x0, pTimeout=0x7fff762f9d28, pReadmask=0x7daca0) at ../../composite/compinit.c:158 #7 0x00451290 in BlockHandler (pTimeout=0x7fff762f9d28, pReadmask=0x7daca0) at ../../dix/dixutils.c:384 #8 0x004eca51 in WaitForSomething (pClientsReady=0xcf2950) at ../../os/WaitFor.c:215 #9 0x0044d5a0 in Dispatch () at ../../dix/dispatch.c:367 ---Type return to continue, or q return to quit--- #10 0x004332bd in main (argc=3, argv=0x7fff762f9f08, envp=value optimized out) at ../../dix/main.c:383 (gdb) -- Lukáš Hejtmánek ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
[PATCH] Port cursorScreenDevPriv to the new dixPrivate API
This was somehow missed when I ported all the DevPrivateKey variables in the source tree. Maybe because it didn't use the proper DevPrivateKey but rather hardcoded the type, so grep din't find it. And I can see why the type was hardcoded: because it's not possible to include privates.h in the file: privates.h depends on dix.h which depends on cursor.h which needs the definition from privates.h. This patch is a) ugly and b) breaks API. So beware of that when you merge it. --- Could you try if this patch helps? Maybe someone can in the meantime come up with a better idea how to untangle the headers. dix/globals.c|3 ++- include/cursor.h |5 - 2 files changed, 6 insertions(+), 2 deletions(-) diff --git a/dix/globals.c b/dix/globals.c index 2585798..d922e02 100644 --- a/dix/globals.c +++ b/dix/globals.c @@ -142,7 +142,8 @@ CursorPtr rootCursor; Bool party_like_its_1989 = FALSE; Bool whiteRoot = FALSE; -int cursorScreenDevPriv[MAXSCREENS]; +static int cursorScreenDevPrivIndex[MAXSCREENS]; +DevPrivateKey *cursorScreenDevPriv = cursorScreenDevPrivIndex; TimeStamp currentTime; TimeStamp lastDeviceEventTime; diff --git a/include/cursor.h b/include/cursor.h index acc95c3..490e945 100644 --- a/include/cursor.h +++ b/include/cursor.h @@ -64,7 +64,10 @@ struct _DeviceIntRec; typedef struct _Cursor *CursorPtr; typedef struct _CursorMetric *CursorMetricPtr; -extern _X_EXPORT int cursorScreenDevPriv[MAXSCREENS]; +/* Because of cyclic references in headers, it's not possible to include + * privates.h in this header. Hence we need to hardcode DevPrivateKey to + * its actualy type. */ +extern _X_EXPORT int **cursorScreenDevPriv; #define CursorScreenKey(pScreen) (cursorScreenDevPriv + (pScreen)-myNum) extern _X_EXPORT CursorPtr rootCursor; ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
