[ANNOUNCE] xf86-video-intel 2.20.1
A week in, grab the brown paper bags, for it is time to reveal a couple of critical bugs that spoilt the 2.20.0 release. Firstly we have the restoration of DRI for i810. I am sure that the solitary user will be overjoyed in a couple of years when a new xserver is forced upon it. That enjoyment will be short-lived as no actual acceleration remains, not even shadow, for the chipset. Perhaps a little more wildly felt, I hope!, will be that the SNA fallbacks were broken on 64-bit machines if they required clipping. One little misplaced cast of a pointer, and the screen is filled with corruption. Among the other tweaks this week: * A bug affecting gen4 handling of trapezoids was fixed, and CPU overhead reduced. https://bugs.freedesktop.org/show_bug.cgi?id=52158 * A fix for a bug causing corruption of a DRI2 unredirected client window that was resized whilst under a compositor. * Support for snoopable buffers on non-LLC architectures, coming to a future kernel. The aim to accelerate transfers between the CPU and the GPU, in particular to dramatically improve readback performance, and to further minimise clflushes. * Improvement to the composite performance on GT2 SandyBridge and IvyBridge devices, in particular the render copy is significantly improved. * Improved handling for when acceleration is disabled, including permitting DRI2 to remain supported even if the X server believes the GPU wedged. * Shadow support was dropped from UXA as it was neither complete nor correct, use SNA instead. -Chris Chris Wilson (83): uxa: Remove Shadow hack intel: Don't use stdbool without declaring it sna: Disable the scanout flush when switch off via DPMS sna: Add a few DBG to show when CPU bos are being used for xfer sna: Discard and recreate the CPU buffer when busy during move-to-cpu sna: Add a couple of DBG options to control accelerated up/downloads sna: Use set-cache-level to allocate snoopable upload buffers sna: Move the disabling of CPU bo for gen4 to the render unit sna/trapezoids: Add some DBG to unaligned fills sna/trapezoids: Fix inplace unaligned fills (on gen4) Wrap defines to avoid redefinition warnings sna: Fixup pixmap validation for sna_copy_area() sna: Disable snoopable uplaod buffers for gen4 sna: Disable snoopable bo for gen4 sna: Share the pixmap migration decision with the BLT composite routines sna: Promote an undamaged pixmap to use the full GPU sna: Fix glyph DBG to include clip extents and actual glyph origin sna: Only drop the clear flag when writing to the GPU pixmap sna: Limit the use of snoopable buffers to read/write uploads sna: Catch the short-circuit path for clearing clear on move-to-gpu as well sna: Avoid the CPU bo readback for render paths sna: Rebalance choice of GPU vs CPU bo sna/dri: Do not allow an exchange to take place on invalid buffers sna/gen7: Bump the number of pixel shader threads for IVB GT2 sna: prefer fbBlt over pixman_blt sna: Tweak fast blt path sna: Allow operation inplace to scanout whilst wedged sna: Allow inplace copies for wedged CopyArea sna: Allow wedged CopyPlane to operate inplace on the destination i810: Split xaa routines from common acceleration methods i810: Replace XAAGet.*ROP() with local tables sna: Maintain a short-lived cache of snoopable CPU bo for older gen sna: Reuse the snoopable cache more frequently for upload buffers sna: Add more DBG for fallback processing sna: Fix processing of the last fallback box sna/trapezoids: Use pixman from within the spans to reduce two-pass operations sna/trapezoids: Only reduce bounded operators to a single pass sna: Enable runtime detection of set-cacheing ioctl sna/gen7: Micro-optimise render copy emission sna/gen6: Micro-optimise render copy emission sna/dri: Allow DRI2 to be loaded even if we are wedged sna/gen4+: Drop unsupported source formats i810: DRI is not dependent upon XAA sna: Re-register the SHM funcs every server generation i810: Handle initialisation without the XAA module present at runtime i810: Correct the double negative and enable XAA when available sna: Tweak order of screen re-initialisation sna/gen4: Hookup composite spans sna: Handle mixed bo/buffers in assertions sna/gen6: Add a simple DBG option to limit usage of either BLT/RENDER sna/gen6: Bump the WM thread count to 80 sna: Remove unused scanout-is-dirty? flag sna: Replace 'sync' flag with equivalent 'flush' sna: Remove topmost unused 'flush' attribute sna: Allow the snoopable upload buffer to take pages from the CPU vma cache sna: Rename kgem_partial_bo to kgem_buffer sna: Update WIP userptr example usage sna/dri: Cleanup ring selection for SNB+ CopyRegion
Re: vesa_drv compatibility question
On 7/22/12 5:38 AM, soul wrote: SUPPORTED HARDWARE The vesa driver supports most VESA-compatible video cards. There are some known exceptions, and those should be listed here. Is there a list of such known exceptions? That is, VESA-compatible cards which are known NOT to work at all or well enough with this driver? I don't know of such a list. Possibly one existed when that man page was written. Secondly, in more general terms, how likely is it to find Laptops (especially), or PC/monitor combinations which are NOT VESA-compatible? Right now, the odds of that are close to zero. In about a year or two, for new hardware, those odds are going to be much closer to one. The UEFI transition is going to mean that the vesa driver will no longer work. Why do you ask? - ajax ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xf86-video-openchrome 0.3.0
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, xf86-video-openchrome 0.3.0 has been released. The 0.3.0 release is a major step forward for the openchrome X.org driver. It brings most of the features that are needed with todays X server. The code has seen a major overhaul, with a lot of new features and a lot of cleanup. It has been tested on most of the available VIA IGPs and we believe there are no regression at this point. However, the testing was done on a limited range of hardware, so your mileage may vary. Please let us know if you have any trouble using it. * New Features : - - TTM/GEM support. - - KMS support. - - Better RandR support. - - XAA removal. - - DGA removal. - - Support for X server 1.13 API. - - Code cleanup and bug fixes. * Known bugs and limitations : - - Dual screen is not fully working. - - EXA compositing is disabled. - - KMS-enabled DRM module is not in upstream kernel yet. Get the tarball from http://www.openchrome.org/releases/ or http://xorg.freedesktop.org/archive/individual/driver/ xf86-video-openchrome-0.3.0.tar.bz2 MD5: dcd7484dcd50959172329390eaafd139 SHA1: 6916be0deaff4a07974590dcef1bc37a1a59e5df xf86-video-openchrome-0.3.0.tar.gz MD5: 237ded982ddd0269b8b22b143622cb3f SHA1: 1a65cfc27238db53e678dc9906ff87cc27af08c5 Starting with the 0.3.0 release, please submit bugs and patches to freedesktop.org bug tracker. https://bugs.freedesktop.org/enter_bug.cgi?product=xorgcomponent=Driver/openchrome The old ticket tracker is kept as a reference only. It is still available at : http://www.openchrome.org/trac/report/1?asc=1sort=ticket Kind regards, the Openchrome team -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iD8DBQFQDYUjuxLT9ttCNJARAsCBAJ4ti1EySAJC5oY9w5bvTx8nAY37rQCeN3oL 1kcl/EHSt7c/d3mfcMqKcUA= =DuI+ -END PGP SIGNATURE- ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: vesa_drv compatibility question
Hello Adam, On Mon, Jul 23, 2012 at 3:49 PM, Adam Jackson a...@redhat.com wrote: On 7/22/12 5:38 AM, soul wrote: SUPPORTED HARDWARE The vesa driver supports most VESA-compatible video cards. There are some known exceptions, and those should be listed here. Is there a list of such known exceptions? That is, VESA-compatible cards which are known NOT to work at all or well enough with this driver? I don't know of such a list. Possibly one existed when that man page was written. Secondly, in more general terms, how likely is it to find Laptops (especially), or PC/monitor combinations which are NOT VESA-compatible? Right now, the odds of that are close to zero. In about a year or two, for new hardware, those odds are going to be much closer to one. The UEFI transition is going to mean that the vesa driver will no longer work. Why do you ask? Thank you for your answer: this is perfectly fine for me. I ask because I am doing a custom LiveCD with a software demo, which as part of the show, should also work on a machine I will not have access to until the actual event. By targeting VESA I am hoping to therefore reduce the risk of an unpleasant surprise at runtime. This UEFI transition seems bad news.. I guess it will be more difficult for these use cases in the future. Thanks, C. ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Cooirdinate transformation matrix does not work properly with evdev and cando touch screen
Hi, I've seen this bug posted already (I commented it on it too), but I figured I might as well ask this here since it doesn't look like the bug report has been touched by anyone in quite a while: When using my netbook's cando touch screen and trying to use the Cooirdinate Transformation Matrix option, the cursor seems to jump around in a specific pattern (I can't describe it very well, but it's already been described here anyway: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/774938 ). The Ubuntu development seems to already have made a patch for it, but it doesn't seem like there is any fix for this upstream yet. Is there any chance this patch could be merged upstream so that the fix is no longer specific to Ubuntu? signature.asc Description: PGP signature ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xf86-input-keyboard 1.6.2
xf86-input-keyboard is the Xorg server keyboard driver for non-evdev OS'es. This release includes bugfixes for Solaris DragonFly BSD, and sets the Device Node Xi property for easier device identification on multi-kbd systems. Alan Coopersmith (5): Solaris: Use uchar_t, not int, for led masks in KIOCSLED/KIOCGLED ioctls Set XI_PROP_DEVICE_NODE property to string from Device option Solaris: ensure Device option is set, even if HAL didn't set it for us Link with $(XORG_LIBS) to support no-undefined linking xf86-input-keyboard 1.6.2 François Tigeot (1): Recognize DragonFly as a BSD system. git tag: xf86-input-keyboard-1.6.2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-keyboard-1.6.2.tar.bz2 MD5: ec2ea4c3faf5af15f2b3192d84252703 SHA1: 8a4f75076231b941011b7c129bd66afe8f261b9a SHA256: 76651a84f5031f7c6ecf075d55989c04a00689642579df6d1a1bee6d5c2e5f8a http://xorg.freedesktop.org/archive/individual/driver/xf86-input-keyboard-1.6.2.tar.gz MD5: db2b57f2fd1fb7e033beff6c96ab9372 SHA1: cdf586fdd1a494225b3b8356e4939b2273223cb7 SHA256: 2e1a26c4c0568e75e686afdbcc103097bd5432ae6e484eb43d92c1458b31b68e -- -Alan Coopersmith- alan.coopersm...@oracle.com Oracle Solaris Engineering - http://blogs.oracle.com/alanc pgpTiUviOp6C7.pgp Description: PGP signature ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xf86-input-evdev 2.7.1
First update to the evdev 2.7 series. This update fixes a couple of bugs and memory leaks. Chase Douglas (2): Report the correct number of touches for MT protocol B devices Fix buffer overrun when populating axis label property array Peter Hutterer (5): Fix inverted horizontal scroll (#46205) Devices configured as mice need REL_X/Y Release mtdev data whenever we close the fd Close the fd when mtdev open fails evdev 2.7.1 git tag: xf86-input-evdev-2.7.1 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-evdev-2.7.1.tar.bz2 MD5: fa7660c6fb09a8365289219d4d1de0e5 xf86-input-evdev-2.7.1.tar.bz2 SHA1: 15847129d7d48bcdba56eae8f60421170aea496d xf86-input-evdev-2.7.1.tar.bz2 SHA256: 1c128bbd34bc17d08cc723c2429cdfe7efc426cb753e38189ffd290002a3b598 xf86-input-evdev-2.7.1.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-evdev-2.7.1.tar.gz MD5: 22b3a764f4c7ad88ff11f2ebba45cae3 xf86-input-evdev-2.7.1.tar.gz SHA1: de2c9a8e10be364422e3a16c9dfce33778c1cf14 xf86-input-evdev-2.7.1.tar.gz SHA256: cfb2aa209ae945c392c105489b2845adba835e89d920ec767d72490cf7132a23 xf86-input-evdev-2.7.1.tar.gz pgpD6jtiNx77L.pgp Description: PGP signature ___ xorg@lists.x.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.x.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[PATCH] hw/xquartz: Various fixes for pseudoramiX.c
Various fixes, applied to panoramiX.c in commit 2b266eda, also need applying to
pseudoramiX.c:
Fix panoramiX request and reply swapping
Set window and screen values in panoramix replies
Prevent buffer overrun in ProcPanoramiXGetScreenSize
These fixes seem to be necessary in order to compile pseudoramiX.c with gcc
pseudoramiX.c: In function 'ProcPseudoramiXGetState':
pseudoramiX.c:221:56: error: call to 'wrong_size' declared with attribute
error: wrong sized variable passed to swap
pseudoramiX.c: In function 'ProcPseudoramiXGetScreenCount':
pseudoramiX.c:250:62: error: call to 'wrong_size' declared with attribute
error: wrong sized variable passed to swap
pseudoramiX.c: In function 'ProcPseudoramiXGetScreenSize':
pseudoramiX.c:283:56: error: call to 'wrong_size' declared with attribute
error: wrong sized variable passed to swap
pseudoramiX.c:284:57: error: call to 'wrong_size' declared with attribute
error: wrong sized variable passed to swap
Signed-off-by: Jon TURNEY jon.tur...@dronecode.org.uk
---
hw/xquartz/pseudoramiX.c | 17 +
1 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/hw/xquartz/pseudoramiX.c b/hw/xquartz/pseudoramiX.c
index c650dd7..ccff64f 100644
--- a/hw/xquartz/pseudoramiX.c
+++ b/hw/xquartz/pseudoramiX.c
@@ -212,10 +212,11 @@ ProcPseudoramiXGetState(ClientPtr client)
rep.length = 0;
rep.sequenceNumber = client-sequence;
rep.state = !noPseudoramiXExtension;
+rep.window = stuff-window;
if (client-swapped) {
swaps(rep.sequenceNumber);
swapl(rep.length);
-swaps(rep.state);
+swapl(rep.window);
}
WriteToClient(client, sizeof(xPanoramiXGetStateReply),rep);
return Success;
@@ -241,10 +242,11 @@ ProcPseudoramiXGetScreenCount(ClientPtr client)
rep.length = 0;
rep.sequenceNumber = client-sequence;
rep.ScreenCount = pseudoramiXNumScreens;
+rep.window = stuff-window;
if (client-swapped) {
swaps(rep.sequenceNumber);
swapl(rep.length);
-swaps(rep.ScreenCount);
+swapl(rep.window);
}
WriteToClient(client, sizeof(xPanoramiXGetScreenCountReply),rep);
return Success;
@@ -261,6 +263,9 @@ ProcPseudoramiXGetScreenSize(ClientPtr client)
TRACE();
+if (stuff-screen = pseudoramiXNumScreens)
+ return BadMatch;
+
REQUEST_SIZE_MATCH(xPanoramiXGetScreenSizeReq);
rc = dixLookupWindow(pWin, stuff-window, client, DixGetAttrAccess);
if (rc != Success)
@@ -274,11 +279,15 @@ ProcPseudoramiXGetScreenSize(ClientPtr client)
// was screenInfo.screens[stuff-screen]-width;
rep.height = pseudoramiXScreens[stuff-screen].h;
// was screenInfo.screens[stuff-screen]-height;
+rep.window = stuff-window;
+rep.screen = stuff-screen;
if (client-swapped) {
swaps(rep.sequenceNumber);
swapl(rep.length);
-swaps(rep.width);
-swaps(rep.height);
+swapl(rep.width);
+swapl(rep.height);
+swapl(rep.window);
+swapl(rep.screen);
}
WriteToClient(client, sizeof(xPanoramiXGetScreenSizeReply),rep);
return Success;
--
1.7.9
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH] Xext/xres.c: Possible buffer underrun
Hi,
I got a crash at free(counts) in ProcXResQueryClientResources() in
Xext/xres.c when using client xrestop.
Traced to an out-by-one error in ResFindAllRes() (please check code and
confirm?).
Fixed, for me (MinGW compilation for Windows), with the patch...
--- ./Xext/save_xres.c 2012-07-10 11:16:44.191904782 +0100
+++ ./Xext/xres.c 2012-07-16 16:19:50.078292944 +0100
@@ -274,7 +274,7 @@
{
int *counts = (int *) cdata;
-counts[(type TypeMask) - 1]++;
+counts[(type TypeMask)]++;
}
static int
Thanks,
Colin Harrison
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH v2] uload unused input modules
Hello, trying to send updated patches again. There is not much actual code in common due to the use of the list macros in this new series. Thanks Michal ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] Xext/xres.c: Possible buffer underrun
On 07/23/2012 03:05 PM, Colin Harrison wrote:
Hi,
I got a crash at free(counts) in ProcXResQueryClientResources() in
Xext/xres.c when using client xrestop.
Traced to an out-by-one error in ResFindAllRes() (please check code and
confirm?).
Fixed, for me (MinGW compilation for Windows), with the patch...
--- ./Xext/save_xres.c 2012-07-10 11:16:44.191904782 +0100
+++ ./Xext/xres.c 2012-07-16 16:19:50.078292944 +0100
@@ -274,7 +274,7 @@
{
int *counts = (int *) cdata;
-counts[(type TypeMask) - 1]++;
+counts[(type TypeMask)]++;
This would probably send wrong resource counts back to clients. It's
better to just skip any resources with RT_NONE as the resource type.
It'd be also nice to know whether it's acceptable to have RT_NONE
resources in the resource database. StoreFontClientFont seems to add
such resources, but I'm not too familiar with that code.
}
static int
Thanks,
Colin Harrison
Regards,
Rami Ylimäki
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [PATCH] dix: fix scale_to_desktop for edge ABS events
On 07/20/2012 04:41 PM, Yufeng Shen wrote: Scale_to_desktop() converts ABS events from device coordinates to screen coordinates: [dev_X_min, dev_X_max] - [screen_X_min, screen_X_max] [dev_Y_min, dev_Y_max] - [screen_Y_min, screen_Y_max] An edge ABS event with X = dev_X_max (e.g., generated from the edge of a touchscreen) will be converted to have screen X value = screen_X_max, which, however, will be filterd out when xserver tries to find proper Window to receive the event, because the range check for a Window to receive events is window_X_min = event_screen_X window_X_max Events with event_screen_X = screen_X_max will fail the test get and rejected by the Window. To fix this, we change the device to screen coordinates mapping to [dev_X_min, dev_X_max] - [screen_X_min, screen_X_max-1] [dev_Y_min, dev_Y_max] - [screen_Y_min, screen_Y_max-1] Signed-off-by: Yufeng Shen mile...@chromium.org --- dix/getevents.c |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/dix/getevents.c b/dix/getevents.c index b78d5ce..9898c6a 100644 --- a/dix/getevents.c +++ b/dix/getevents.c @@ -890,9 +890,9 @@ scale_to_desktop(DeviceIntPtr dev, ValuatorMask *mask, /* scale xy to desktop coordinates */ *screenx = rescaleValuatorAxis(x, dev-valuator-axes + 0, NULL, - screenInfo.x, screenInfo.width); + screenInfo.x, screenInfo.width - 1); *screeny = rescaleValuatorAxis(y, dev-valuator-axes + 1, NULL, - screenInfo.y, screenInfo.height); + screenInfo.y, screenInfo.height - 1); *devx = x; *devy = y; The logic seems correct to me. We need to map to: [screen_min, screen_max) for each axis. Reviewed-by: Chase Douglas chase.doug...@canonical.com ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
Re: [Nouveau] [PATCH 9/9] dri2: Fix corner case crash for swaplimit 1
12.07.2012 22:39, Anssi Hannula kirjoitti:
Hi!
On 16.02.2012 02:45, Mario Kleiner wrote:
If a swaplimit 1 is set on a server which
supports the swaplimit api (XOrg 1.12.0+),
the following can happen:
1. Client calls glXSwapBuffersMscOML() with a
swap target 1 vblank in the future, or a
client calls glXSwapbuffers() while the swap
interval is set to 1 (unusual but possible).
2. nouveau_dri2_finish_swap() is therefore called
only at the target vblank, instead of immediately.
3. Because of the deferred execution of
nouveu_dri2_finish_swap(), the OpenGL client
can call x-servers DRI2GetBuffersWithFormat()
before nouveau_dri2_finish_swap() executes and
it deletes pixmaps that would be needed by
nouveau_dri2_finish_swap() -- Segfault -- Crash.
Prevent this: When a swap is scheduled into the
future, we temporarily reduce the swaplimit to 1
until nouveau_dri2_finish_swap() is done, then
restore it to its original value. This throttles
the client inside the server in DRI2ThrottleClient()
before it can call the evil DRI2GetbuffersWithFormat().
The client will still be released one video refresh
interval before swap completion, so there is still
some potential win.
This doesn't affect the common case of swapping at
the next vblank, where this throttling is not needed
or done.
After upgrading my system to X server 1.12.3, I've started to
experience some crashes/freezes related to apparent memory
corruption.
Debugging with valgrind and gdb, it seems to me like the evil
DRI2GetbuffersWithFormat() can be called before swap even when
target_msc == current_msc + 1. This results in writes+reads to
freed memory when the vblank event is finally being handled.
I'm not an Xorg/drm expert, but with a glance at the code I
didn't see anything that would/should prevent
DRI2GetbuffersWithFormat() from being called before the vblank
event is handled. Even if the event is immediately sent by the
kernel, isn't it possible that the X server services some other
requests before the event is dispatched?
Am I missing something, or is that a bug?
In any case, I'm running ddx 1.0.1, xserver 1.12.3, libdrm 2.4.37,
kernel 3.4.4, and I have Option GLXVBlank true.
Here's one of the invalid write errors:
==24537== Invalid write of size 4
==24537==at 0x8D45029: nouveau_bo_name_get (nouveau.c:426)
==24537==by 0x8B1EFFD: nouveau_dri2_finish_swap (nouveau_dri2.c:173)
==24537==by 0x8B1F65F: nouveau_dri2_vblank_handler (nouveau_dri2.c:598)
==24537==by 0x8707BA0: drmHandleEvent (xf86drmMode.c:808)
==24537==by 0x8B37BC5: drmmode_wakeup_handler (drmmode_display.c:1447)
==24537==by 0x43EA15: WakeupHandler (dixutils.c:421)
==24537==by 0x5D7429: WaitForSomething (WaitFor.c:224)
==24537==by 0x430B8B: Dispatch (dispatch.c:357)
==24537==by 0x421D6C: main (main.c:288)
==24537== Address 0xdd7c6d4 is 4 bytes inside a block of size 40 free'd
==24537==at 0x4C25A9E: free (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==24537==by 0x890E5A4: update_dri2_drawable_buffers (dri2.c:415)
==24537==by 0x890E97D: do_get_buffers (dri2.c:525)
==24537==by 0x890EB60: DRI2GetBuffersWithFormat (dri2.c:582)
==24537==by 0x8910A7E: ProcDRI2GetBuffersWithFormat (dri2ext.c:299)
==24537==by 0x8911256: ProcDRI2Dispatch (dri2ext.c:564)
==24537==by 0x430DDF: Dispatch (dispatch.c:428)
==24537==by 0x421D6C: main (main.c:288)
I stored some additional data regarding the vblank event request in
nouveau_dri2_vblank_state, so that I could retrieve the information
at invalid write time:
(gdb) print *(struct nouveau_dri2_vblank_state*) event_data
$1 = {action = SWAP, client = 0x7740b20, draw = 37748775, dst =
0xdd7c6d0, src = 0xbd1f5a0, func = 0x8910bf2 DRI2SwapEvent, data =
0x99247b0, frame = 302185, current_msc = 302184, target_msc = 302185,
remainder = 0, divisor = 0, hit = 0}
As you can see, in this event target_msc was current_msc + 1, but
still DRI2GetBuffersWithFormat() apparently managed to get called
first (and since swap limit was not altered, the call was not
throttled).
I've workarounded this locally for now with:
Option SwapLimit 1
But I guess something should still be done about this memory corruption
issue...
Signed-off-by: Mario Kleiner mario.klei...@tuebingen.mpg.de
---
src/nouveau_dri2.c | 26 ++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/src/nouveau_dri2.c b/src/nouveau_dri2.c
index f0c7fec..7878a5a 100644
--- a/src/nouveau_dri2.c
+++ b/src/nouveau_dri2.c
@@ -445,6 +445,26 @@ nouveau_dri2_schedule_swap(ClientPtr client,
DrawablePtr draw,
if (*target_msc == 0)
*target_msc = 1;
+#if DRI2INFOREC_VERSION = 6
+/* Is this a swap in the future, ie. the vblank event will
+ * not be immediately dispatched, but only at a future vblank?
+ * If so, we need to
[PATCH 1/7] xfree86/loader: Do not unload sibling modules.
Ordering of sibling modules is internal to the loader implementation.
Unloading siblings following the requested module in the sibling list
leads to unexpected unloading of seemingly random modules.
Signed-off-by: Michal Suchanek hramr...@gmail.com
---
hw/xfree86/loader/loadmod.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/hw/xfree86/loader/loadmod.c b/hw/xfree86/loader/loadmod.c
index 2347b8e..65bf055 100644
--- a/hw/xfree86/loader/loadmod.c
+++ b/hw/xfree86/loader/loadmod.c
@@ -1099,16 +1099,16 @@ UnloadModuleOrDriver(ModuleDescPtr mod)
else
LogMessageVerbSigSafe(X_INFO, 3, UnloadModule: \%s\\n, mod-name);
+RemoveChild(mod);
if (mod-TearDownData != ModuleDuplicated) {
if ((mod-TearDownProc) (mod-TearDownData))
mod-TearDownProc(mod-TearDownData);
LoaderUnload(mod-name, mod-handle);
}
-if (mod-child)
+while (mod-child)
UnloadModuleOrDriver(mod-child);
-if (mod-sib)
-UnloadModuleOrDriver(mod-sib);
+
free(mod-path);
free(mod-name);
free(mod);
--
1.7.10.4
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 3/7] xfree86: Convert xf86InputDevs to nt_list_ macros.
Signed-off-by: Michal Suchanek hramr...@gmail.com
---
hw/xfree86/common/xf86Helper.c |2 +-
hw/xfree86/common/xf86Xinput.c | 23 ++-
2 files changed, 7 insertions(+), 18 deletions(-)
diff --git a/hw/xfree86/common/xf86Helper.c b/hw/xfree86/common/xf86Helper.c
index f681a85..90484bb 100644
--- a/hw/xfree86/common/xf86Helper.c
+++ b/hw/xfree86/common/xf86Helper.c
@@ -153,7 +153,7 @@ xf86LookupInput(const char *name)
{
InputInfoPtr p;
-for (p = xf86InputDevs; p != NULL; p = p-next) {
+nt_list_for_each_entry(p, xf86InputDevs, next) {
if (strcmp(name, p-name) == 0)
return p;
}
diff --git a/hw/xfree86/common/xf86Xinput.c b/hw/xfree86/common/xf86Xinput.c
index bee407b..7b368fe 100644
--- a/hw/xfree86/common/xf86Xinput.c
+++ b/hw/xfree86/common/xf86Xinput.c
@@ -725,15 +725,14 @@ xf86AllocateInput(void)
static void
xf86AddInput(InputDriverPtr drv, InputInfoPtr pInfo)
{
-InputInfoPtr *prev = NULL;
-
pInfo-drv = drv;
pInfo-module = DuplicateModule(drv-module, NULL);
-for (prev = xf86InputDevs; *prev; prev = (*prev)-next);
-
-*prev = pInfo;
-pInfo-next = NULL;
+/* the append macro is kind of useless */
+if (xf86InputDevs)
+nt_list_append(pInfo, xf86InputDevs, InputInfoRec, next);
+else
+xf86InputDevs = pInfo;
xf86CollectInputOptions(pInfo, (const char **) drv-default_options);
xf86OptionListReport(pInfo-options);
@@ -761,17 +760,7 @@ xf86DeleteInput(InputInfoPtr pInp, int flags)
FreeInputAttributes(pInp-attrs);
/* Remove the entry from the list. */
-if (pInp == xf86InputDevs)
-xf86InputDevs = pInp-next;
-else {
-InputInfoPtr p = xf86InputDevs;
-
-while (p p-next != pInp)
-p = p-next;
-if (p)
-p-next = pInp-next;
-/* Else the entry wasn't in the xf86InputDevs list (ignore this). */
-}
+nt_list_del(pInp, xf86InputDevs, InputInfoRec, next);
free(pInp-driver);
free(pInp-name);
--
1.7.10.4
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 4/7] xfree86: Convert xf86InputDriverList to xorg_list.
Signed-off-by: Michal Suchanek hramr...@gmail.com
---
hw/xfree86/common/xf86Globals.c |2 --
hw/xfree86/common/xf86Helper.c | 41 ---
hw/xfree86/common/xf86InPriv.h |4
hw/xfree86/common/xf86Xinput.h |3 ++-
hw/xfree86/doc/ddxDesign.xml|8 +---
5 files changed, 28 insertions(+), 30 deletions(-)
diff --git a/hw/xfree86/common/xf86Globals.c b/hw/xfree86/common/xf86Globals.c
index 7df7a80..2f5e802 100644
--- a/hw/xfree86/common/xf86Globals.c
+++ b/hw/xfree86/common/xf86Globals.c
@@ -156,8 +156,6 @@ Bool xf86DoConfigure = FALSE;
Bool xf86DoShowOptions = FALSE;
DriverPtr *xf86DriverList = NULL;
int xf86NumDrivers = 0;
-InputDriverPtr *xf86InputDriverList = NULL;
-int xf86NumInputDrivers = 0;
int xf86NumScreens = 0;
int xf86NumGPUScreens = 0;
diff --git a/hw/xfree86/common/xf86Helper.c b/hw/xfree86/common/xf86Helper.c
index 90484bb..187cf1f 100644
--- a/hw/xfree86/common/xf86Helper.c
+++ b/hw/xfree86/common/xf86Helper.c
@@ -62,6 +62,8 @@
#include sys/resource.h
#endif
+static struct xorg_list *xf86InputDriverList = NULL;
+
static int xf86ScrnInfoPrivateCount = 0;
/* Add a pointer to a new DriverRec to xf86DriverList */
@@ -109,41 +111,40 @@ xf86DeleteDriver(int drvIndex)
void
xf86AddInputDriver(InputDriverPtr driver, pointer module, int flags)
{
+InputDriverPtr rec;
/* Don't add null entries */
if (!driver)
return;
-if (xf86InputDriverList == NULL)
-xf86NumInputDrivers = 0;
+if (xf86InputDriverList == NULL) {
+xf86InputDriverList = malloc(sizeof(struct xorg_list));
+xorg_list_init(xf86InputDriverList);
+}
-xf86NumInputDrivers++;
-xf86InputDriverList = xnfrealloc(xf86InputDriverList,
- xf86NumInputDrivers *
- sizeof(InputDriverPtr));
-xf86InputDriverList[xf86NumInputDrivers - 1] =
-xnfalloc(sizeof(InputDriverRec));
-*xf86InputDriverList[xf86NumInputDrivers - 1] = *driver;
-xf86InputDriverList[xf86NumInputDrivers - 1]-module = module;
+rec = calloc(sizeof(InputDriverRec),1);
+*rec = *driver;
+rec-module = module;
+xorg_list_add(rec-entry, xf86InputDriverList);
}
void
-xf86DeleteInputDriver(int drvIndex)
+xf86DeleteInputDriver(InputDriverPtr driver)
{
-if (xf86InputDriverList[drvIndex] xf86InputDriverList[drvIndex]-module)
-UnloadModule(xf86InputDriverList[drvIndex]-module);
-free(xf86InputDriverList[drvIndex]);
-xf86InputDriverList[drvIndex] = NULL;
+UnloadModule(driver-module);
+xorg_list_del(driver-entry);
+free(driver);
}
InputDriverPtr
xf86LookupInputDriver(const char *name)
{
-int i;
+InputDriverPtr iterator;
+if (!xf86InputDriverList)
+return NULL;
-for (i = 0; i xf86NumInputDrivers; i++) {
-if (xf86InputDriverList[i] xf86InputDriverList[i]-driverName
-xf86NameCmp(name, xf86InputDriverList[i]-driverName) == 0)
-return xf86InputDriverList[i];
+xorg_list_for_each_entry(iterator, xf86InputDriverList, entry) {
+if(xf86NameCmp(iterator-driverName, name) == 0)
+return iterator;
}
return NULL;
}
diff --git a/hw/xfree86/common/xf86InPriv.h b/hw/xfree86/common/xf86InPriv.h
index 5826ac3..6f4d8c1 100644
--- a/hw/xfree86/common/xf86InPriv.h
+++ b/hw/xfree86/common/xf86InPriv.h
@@ -33,10 +33,6 @@
#ifndef _xf86InPriv_h
#define _xf86InPriv_h
-/* xf86Globals.c */
-extern InputDriverPtr *xf86InputDriverList;
-extern int xf86NumInputDrivers;
-
/* xf86Helper.c */
InputDriverPtr xf86LookupInputDriver(const char *name);
diff --git a/hw/xfree86/common/xf86Xinput.h b/hw/xfree86/common/xf86Xinput.h
index 35c38a5..8d3ce75 100644
--- a/hw/xfree86/common/xf86Xinput.h
+++ b/hw/xfree86/common/xf86Xinput.h
@@ -76,6 +76,7 @@ typedef struct _InputDriverRec {
struct _InputInfoRec * pInfo, int flags);
pointer module;
const char **default_options;
+struct xorg_list entry;
} InputDriverRec, *InputDriverPtr;
/* This is to input devices what the ScrnInfoRec is to screens. */
@@ -180,7 +181,7 @@ InputInfoPtr xf86AllocateInput(void);
/* xf86Helper.c */
extern _X_EXPORT void xf86AddInputDriver(InputDriverPtr driver, pointer module,
int flags);
-extern _X_EXPORT void xf86DeleteInputDriver(int drvIndex);
+extern _X_EXPORT void xf86DeleteInputDriver(InputDriverPtr driver);
extern _X_EXPORT InputDriverPtr xf86LookupInputDriver(const char *name);
extern _X_EXPORT InputInfoPtr xf86LookupInput(const char *name);
extern _X_EXPORT void xf86DeleteInput(InputInfoPtr pInp, int flags);
diff --git a/hw/xfree86/doc/ddxDesign.xml b/hw/xfree86/doc/ddxDesign.xml
index 4c2ca47..e23ae61 100644
--- a/hw/xfree86/doc/ddxDesign.xml
+++ b/hw/xfree86/doc/ddxDesign.xml
@@ -719,9 +719,11 @@ Here is what functionInitOutput()/function does:
essential details and driver entry
[PATCH 6/7] xfree86: unload unused input drivers
Signed-off-by: Michal Suchanek hramr...@gmail.com
---
hw/xfree86/common/xf86Helper.c |7 +++
hw/xfree86/common/xf86Xinput.c |4
2 files changed, 11 insertions(+)
diff --git a/hw/xfree86/common/xf86Helper.c b/hw/xfree86/common/xf86Helper.c
index 187cf1f..350b089 100644
--- a/hw/xfree86/common/xf86Helper.c
+++ b/hw/xfree86/common/xf86Helper.c
@@ -130,6 +130,13 @@ xf86AddInputDriver(InputDriverPtr driver, pointer module,
int flags)
void
xf86DeleteInputDriver(InputDriverPtr driver)
{
+/* Maybe should check that the driver is non-null and in the list. */
+
+/* The loader does not return error from UnloadModule so check that the
+ * driver can be unloaded. */
+if (driver-module !CanUnloadModule(driver-module))
+return; /* cannot unload (yet) */
+
UnloadModule(driver-module);
xorg_list_del(driver-entry);
free(driver);
diff --git a/hw/xfree86/common/xf86Xinput.c b/hw/xfree86/common/xf86Xinput.c
index 7b368fe..8b29198 100644
--- a/hw/xfree86/common/xf86Xinput.c
+++ b/hw/xfree86/common/xf86Xinput.c
@@ -752,6 +752,10 @@ xf86DeleteInput(InputInfoPtr pInp, int flags)
if (pInp-module)
UnloadModule(pInp-module);
+/* Attempt to unload the driver */
+if (pInp-drv)
+xf86DeleteInputDriver(pInp-drv);
+
/* This should *really* be handled in drv-UnInit(dev) call instead, but
* if the driver forgets about it make sure we free it or at least crash
* with flying colors */
--
1.7.10.4
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[PATCH 5/7] xfree86/loader: Split off some loader code into separate query functions.
* Add CanUnloadModule
Signed-off-by: Michal Suchanek hramr...@gmail.com
---
hw/xfree86/loader/loaderProcs.h |5 +
hw/xfree86/loader/loadmod.c | 42 ++-
2 files changed, 42 insertions(+), 5 deletions(-)
diff --git a/hw/xfree86/loader/loaderProcs.h b/hw/xfree86/loader/loaderProcs.h
index 8b4b53f..5028554 100644
--- a/hw/xfree86/loader/loaderProcs.h
+++ b/hw/xfree86/loader/loaderProcs.h
@@ -87,6 +87,11 @@ unsigned long LoaderGetModuleVersion(ModuleDescPtr mod);
void LoaderResetOptions(void);
void LoaderSetOptions(unsigned long);
+Bool IsBuiltinModule(ModuleDescPtr mod);
+Bool IsDuplicated(ModuleDescPtr mod);
+Bool IsDuplicateModule(ModuleDescPtr mod);
+Bool CanUnloadModule(ModuleDescPtr mod);
+
/* Options for LoaderSetOptions */
#define LDR_OPT_ABI_MISMATCH_NONFATAL 0x0001
diff --git a/hw/xfree86/loader/loadmod.c b/hw/xfree86/loader/loadmod.c
index a6adae9..8a48adb 100644
--- a/hw/xfree86/loader/loadmod.c
+++ b/hw/xfree86/loader/loadmod.c
@@ -785,7 +785,7 @@ LoadSubModule(pointer _parent, const char *module,
submod = doLoadModule(module, NULL, subdirlist, patternlist, options,
modreq, errmaj, errmin);
-if (submod submod != (ModuleDescPtr) 1) {
+if (submod !IsBuiltinModule(submod)) {
parent-child = AddSibling(parent-child, submod);
submod-parent = parent;
}
@@ -803,6 +803,19 @@ NewModuleDesc(const char *name)
return mdp;
}
+/* An advisory function. When true is returned unloading the module should be
+ * safe. Uload can be attempted nonetheless. */
+int CanUnloadModule(ModuleDescPtr mod)
+{
+if (IsBuiltinModule(mod))
+return 0;
+if (IsDuplicated(mod))
+return 0;
+/* Neither of the above can be true for modules for which IsDuplicateModule
+ * is true. */
+return 1;
+}
+
ModuleDescPtr
DuplicateModule(ModuleDescPtr mod, ModuleDescPtr parent)
{
@@ -1084,10 +1097,29 @@ UnloadModule(pointer mod)
UnloadModuleOrDriver((ModuleDescPtr) mod);
}
+/* Is given module builtin? */
+Bool IsBuiltinModule(ModuleDescPtr mod)
+{
+return (mod == (ModuleDescPtr) 1);
+}
+
+/* Is given module duplicate of another? */
+Bool IsDuplicateModule(ModuleDescPtr mod)
+{
+return (mod-TearDownData == ModuleDuplicated);
+}
+
+/* Do duplicates of given module exist? */
+Bool IsDuplicated(ModuleDescPtr mod)
+{
+/* cannot tell until reference counting is added */
+return TRUE;
+}
+
static void
UnloadModuleOrDriver(ModuleDescPtr mod)
{
-if (mod == (ModuleDescPtr) 1)
+if (IsBuiltinModule(mod))
return;
if (mod == NULL || mod-name == NULL)
@@ -1100,7 +1132,7 @@ UnloadModuleOrDriver(ModuleDescPtr mod)
LogMessageVerbSigSafe(X_INFO, 3, UnloadModule: \%s\\n, mod-name);
RemoveChild(mod);
-if (mod-TearDownData != ModuleDuplicated) {
+if (!IsDuplicateModule(mod)) {
if ((mod-TearDownProc) (mod-TearDownData))
mod-TearDownProc(mod-TearDownData);
LoaderUnload(mod-name, mod-handle);
@@ -1120,7 +1152,7 @@ UnloadSubModule(pointer _mod)
ModuleDescPtr mod = (ModuleDescPtr) _mod;
/* Some drivers are calling us on built-in submodules, ignore them */
-if (mod == (ModuleDescPtr) 1)
+if (IsBuiltinModule(mod))
return;
RemoveChild(mod);
UnloadModuleOrDriver(mod);
@@ -1244,7 +1276,7 @@ LoaderGetCanonicalName(const char *modname, PatternPtr
patterns)
unsigned long
LoaderGetModuleVersion(ModuleDescPtr mod)
{
-if (!mod || mod == (ModuleDescPtr) 1 || !mod-VersionInfo)
+if (!mod || IsBuiltinModule(mod) || !mod-VersionInfo)
return 0;
return MODULE_VERSION_NUMERIC(mod-VersionInfo-majorversion,
--
1.7.10.4
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[RFC PATCH] sync: Fix logic error from b55bf248581dc66321b24b29f199f6dc8d02db1b
That commit adds two hunks, and I _think_ they're backwards. It adds
code to modify bracket_greater on NegativeTransition triggers, and
bracket_less on PositiveTransition triggers. That breaks symmetry with
the surrounding code; the code as of this commit could probably be
simplified further.
I can't keep the sync trigger rules in my head for more than about five
minutes at a time, so I'm sending this on for more eyes. RHEL 6.3's
xserver is shipping with b55bf248 reverted:
https://bugzilla.redhat.com/show_bug.cgi?id=748704#c33
And there appear to be some upstream reports of the same issue:
https://bugzilla.gnome.org/show_bug.cgi?id=658955
So I'd like to get this sorted out.
Signed-off-by: Adam Jackson a...@redhat.com
---
Xext/sync.c | 24
1 files changed, 12 insertions(+), 12 deletions(-)
diff --git a/Xext/sync.c b/Xext/sync.c
index b8f094d..4d11992 100644
--- a/Xext/sync.c
+++ b/Xext/sync.c
@@ -1038,15 +1038,15 @@ SyncComputeBracketValues(SyncCounter * pCounter)
pnewltval = psci-bracket_less;
}
else if (XSyncValueEqual(pCounter-value, pTrigger-test_value)
- XSyncValueLessThan(pTrigger-test_value,
-psci-bracket_greater)) {
+ XSyncValueGreaterThan(pTrigger-test_value,
+ psci-bracket_less)) {
/*
* The value is exactly equal to our threshold. We want one
- * more event in the positive direction to ensure we pick up
- * when the value *exceeds* this threshold.
+ * more event in the negative direction to ensure we pick up
+ * when the value is less than this threshold.
*/
-psci-bracket_greater = pTrigger-test_value;
-pnewgtval = psci-bracket_greater;
+psci-bracket_less = pTrigger-test_value;
+pnewltval = psci-bracket_less;
}
}
else if (pTrigger-test_type == XSyncPositiveTransition
@@ -1058,15 +1058,15 @@ SyncComputeBracketValues(SyncCounter * pCounter)
pnewgtval = psci-bracket_greater;
}
else if (XSyncValueEqual(pCounter-value, pTrigger-test_value)
- XSyncValueGreaterThan(pTrigger-test_value,
- psci-bracket_less)) {
+ XSyncValueLessThan(pTrigger-test_value,
+psci-bracket_greater)) {
/*
* The value is exactly equal to our threshold. We want one
- * more event in the negative direction to ensure we pick up
- * when the value is less than this threshold.
+ * more event in the positive direction to ensure we pick up
+ * when the value *exceeds* this threshold.
*/
-psci-bracket_less = pTrigger-test_value;
-pnewltval = psci-bracket_less;
+psci-bracket_greater = pTrigger-test_value;
+pnewgtval = psci-bracket_greater;
}
}
} /* end for each trigger */
--
1.7.7.6
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: http://lists.x.org/mailman/listinfo/xorg-devel
[ANNOUNCE] xf86-input-evdev 2.7.1
First update to the evdev 2.7 series. This update fixes a couple of bugs and memory leaks. Chase Douglas (2): Report the correct number of touches for MT protocol B devices Fix buffer overrun when populating axis label property array Peter Hutterer (5): Fix inverted horizontal scroll (#46205) Devices configured as mice need REL_X/Y Release mtdev data whenever we close the fd Close the fd when mtdev open fails evdev 2.7.1 git tag: xf86-input-evdev-2.7.1 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-evdev-2.7.1.tar.bz2 MD5: fa7660c6fb09a8365289219d4d1de0e5 xf86-input-evdev-2.7.1.tar.bz2 SHA1: 15847129d7d48bcdba56eae8f60421170aea496d xf86-input-evdev-2.7.1.tar.bz2 SHA256: 1c128bbd34bc17d08cc723c2429cdfe7efc426cb753e38189ffd290002a3b598 xf86-input-evdev-2.7.1.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-input-evdev-2.7.1.tar.gz MD5: 22b3a764f4c7ad88ff11f2ebba45cae3 xf86-input-evdev-2.7.1.tar.gz SHA1: de2c9a8e10be364422e3a16c9dfce33778c1cf14 xf86-input-evdev-2.7.1.tar.gz SHA256: cfb2aa209ae945c392c105489b2845adba835e89d920ec767d72490cf7132a23 xf86-input-evdev-2.7.1.tar.gz pgpR9x1l9irPr.pgp Description: PGP signature ___ xorg-announce mailing list xorg-announce@lists.x.org http://lists.x.org/mailman/listinfo/xorg-announce
[Bug 35457] [rs690m] Graphics corruption with ati x1200
https://bugs.freedesktop.org/show_bug.cgi?id=35457 --- Comment #44 from Brian aeon.descrip...@gmail.com 2012-07-23 06:20:41 PDT --- It's disappointing, but I think there are just too many bugs and not enough coders to fix them, and they've got to prioritize. -- on top of that, there's not a *really* good method out there of evaluating the impact of a problem. This is obviously a high-impact problem, considering how common the card is, but it's slipped between the cracks. As to your idea -- I think that radeonhd drivers are incompatible with the newer versions of X -- which is why they were phased out anyways. Unfortunately, the newer drivers obviously don't work right for a lot of people. The best bet to getting a fix is probably emailing the maintainers of the new driver -- getting on mailing lists and discussing it. I long ago gave up on fighting this particular fight. If it helps, this is definitely a sideport ram issue, and disabling sideport ram in the BIOS fixes the problem -- however, many BIOSes do not allow you to do this. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: No DVI output on ATI Xpress 200 - reopen
could it be possible that I'd try to communicate with LCD display thru ddc using i2c-dev module to probe how to access it? maybe this would help? 2012/7/19 Alex Deucher alexdeuc...@gmail.com: On Thu, Jul 19, 2012 at 7:25 AM, Przemysław Tomczyk tomczyk.prze...@gmail.com wrote: Hi and hello to the list, Recently I've received workstation with Xpress 200 card, no DVI output. Kernel is 3.4.4. DVI output goes blank as soon as KMS kicks in. Xorg.log mentions no EDID for DVI-0, but forcing edid from file using drm_kms_helper module didn't help. Now i'm getting DVI: Failed to assign ddc bus! Check dmesg for i2c errors., bot no i2c errors in dmesg output. in /sys i c an see nodes for 2 buses: #cat /sys/devices/pci\:00/\:00\:01.0/\:01\:05.0/i2c-2/name Radeon i2c bit bus VGA_DDC # cat /sys/devices/pci\:00/\:00\:01.0/\:01\:05.0/i2c-1/name Radeon i2c bit bus DVI_DDC I have bios dump ready to attach on request. Please open a bug: https://bugs.freedesktop.org/ Product: DRI, component: DRM/Radeon and attach your xorg log, dmesg output, and a copy of your vbios. To get a copy of your vbios: (as root) (use lspci to get the bus id) cd /sys/bus/pci/devices/pci bus id echo 1 rom cat rom /tmp/vbios.rom echo 0 rom Thanks! Alex ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
[Bug 52330] Triple monitor desktop intermittent slow updates
https://bugs.freedesktop.org/show_bug.cgi?id=52330 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Attachment #64478|text/x-log |text/plain mime type|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
[Bug 52330] Triple monitor desktop intermittent slow updates
https://bugs.freedesktop.org/show_bug.cgi?id=52330 --- Comment #2 from Alex Deucher ag...@yahoo.com 2012-07-23 14:53:00 PDT --- This isn't an issue with multi-head per se. It's more of an issue with software fallbacks. When there is a software fallback the pixmap where fallback has to be handled has to be migrated into CPU accessible memory and the larger the pixmap, the more data has to be migrated. That's why it's more noticeable when you have a larger desktop. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: No DVI output on ATI Xpress 200 - reopen
On Mon, Jul 23, 2012 at 6:06 AM, Przemysław Tomczyk tomczyk.prze...@gmail.com wrote: could it be possible that I'd try to communicate with LCD display thru ddc using i2c-dev module to probe how to access it? maybe this would help? You can try accessing the i2c buses exposed by the radeon driver and seeing which one (if any) has the edid for the DVI port using i2c_detect or something similar. Let me know what you find out. Alex 2012/7/19 Alex Deucher alexdeuc...@gmail.com: On Thu, Jul 19, 2012 at 7:25 AM, Przemysław Tomczyk tomczyk.prze...@gmail.com wrote: Hi and hello to the list, Recently I've received workstation with Xpress 200 card, no DVI output. Kernel is 3.4.4. DVI output goes blank as soon as KMS kicks in. Xorg.log mentions no EDID for DVI-0, but forcing edid from file using drm_kms_helper module didn't help. Now i'm getting DVI: Failed to assign ddc bus! Check dmesg for i2c errors., bot no i2c errors in dmesg output. in /sys i c an see nodes for 2 buses: #cat /sys/devices/pci\:00/\:00\:01.0/\:01\:05.0/i2c-2/name Radeon i2c bit bus VGA_DDC # cat /sys/devices/pci\:00/\:00\:01.0/\:01\:05.0/i2c-1/name Radeon i2c bit bus DVI_DDC I have bios dump ready to attach on request. Please open a bug: https://bugs.freedesktop.org/ Product: DRI, component: DRM/Radeon and attach your xorg log, dmesg output, and a copy of your vbios. To get a copy of your vbios: (as root) (use lspci to get the bus id) cd /sys/bus/pci/devices/pci bus id echo 1 rom cat rom /tmp/vbios.rom echo 0 rom Thanks! Alex ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
[Bug 52330] Triple monitor desktop intermittent slow updates
https://bugs.freedesktop.org/show_bug.cgi?id=52330 --- Comment #3 from gitbisec...@gmail.com 2012-07-23 15:54:21 PDT --- Yes that makes sense. Thanks for pointing that out. Do you know of any obvious points in the code where this might happen? From my log it seems drivers get loaded appropriately. Somehow this clears itself up after a desktop resizing using xrandr. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
[Bug 52407] New: [GLAMOR] xserver segfaults on startup (with backtrace).
https://bugs.freedesktop.org/show_bug.cgi?id=52407 Bug #: 52407 Summary: [GLAMOR] xserver segfaults on startup (with backtrace). Classification: Unclassified Product: xorg Version: unspecified Platform: x86-64 (AMD64) OS/Version: Linux (All) Status: NEW Severity: normal Priority: medium Component: Driver/Radeon AssignedTo: xorg-driver-ati@lists.x.org ReportedBy: high.entr...@web.de QAContact: xorg-t...@lists.x.org Created attachment 64559 -- https://bugs.freedesktop.org/attachment.cgi?id=64559 backtrace Hi, I wanted to give the newly added GLAMOR acceleration a try. Unfortunately it segfaults immediately. Find a backtrace attached. X.Org Server 1.12.3 libdrm, mesa, glamor and DDX from master (today). (glamor 0.4.1 segfaults also) GPU Radeon HD 4850 (running in 2 screen Zaphod mode) -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
[Bug 52407] [GLAMOR] xserver segfaults on startup (with backtrace).
https://bugs.freedesktop.org/show_bug.cgi?id=52407 --- Comment #1 from Felix Miata mrma...@earthlink.net 2012-07-23 18:24:48 PDT --- Mime type is set wrong on attachment. Gecko won't open it. Are you using 100% automagic, or are you using any config file in /etc/X11/? cf. bug 51640 -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
[Bug 52407] [GLAMOR] xserver segfaults on startup (with backtrace).
https://bugs.freedesktop.org/show_bug.cgi?id=52407 --- Comment #2 from Till Matthiesen high.entr...@web.de 2012-07-23 18:35:39 UTC --- Created attachment 64560 -- https://bugs.freedesktop.org/attachment.cgi?id=64560 xorg.conf Hi Felix, find the xorg.conf attached (hope the mime type is fine this time). How can I use automagic when targeting Zaphod mode? AFAIK I _have_ to specify separate screens in xorg.conf. Otherwise I always ended up with a single big framebuffer using xrandr. I don't want that. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
[Bug 52407] [GLAMOR] xserver segfaults on startup (with backtrace).
https://bugs.freedesktop.org/show_bug.cgi?id=52407 Alex Deucher ag...@yahoo.com changed: What|Removed |Added Attachment #64559|application/octet-stream|text/plain mime type|| -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
[Bug 52407] [GLAMOR] xserver segfaults on startup (with backtrace).
https://bugs.freedesktop.org/show_bug.cgi?id=52407 --- Comment #3 from Alex Deucher ag...@yahoo.com 2012-07-23 18:56:25 PDT --- I don't think glamor will work with zaphod mode at the moment. Does it work ok if you use non-zaphod mode? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
[Bug 52407] [GLAMOR] xserver segfaults on startup (with backtrace).
https://bugs.freedesktop.org/show_bug.cgi?id=52407 --- Comment #4 from Till Matthiesen high.entr...@web.de 2012-07-23 19:35:48 PDT --- Indeed, Alex is right. It works for the single screen configuration. So I have to revert to EXA, obviously not missing much yet: A quick test with the scrolling performance of a long Facebook page in Google Chrome 21.x has been more than disappointing. It's awfully slow. Are there any technical restrictions concerning Glamor+Zaphod mode? I plan to get new card in the next months. AFAIK buying = HD 7000 series card means 2D acceleration is _only_ provided through Glamor. Without Zaphod mode and decent 2D performance this does not sound like a good deal to me. :/ -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: No DVI output on ATI Xpress 200 - reopen
so. the box has 2 monitors (different) connected, thru VGA and DVI-D after inserting i2c-dev and eeprom modules, i've run i2cdetect from debian's i2c-tools package. output was: i2c-0 smbus SMBus PIIX4 adapter at 0b00 SMBus adapter i2c-1 i2c Radeon i2c bit bus DVI_DDC I2C adapter i2c-2 i2c Radeon i2c bit bus VGA_DDC I2C adapter i2c-3 i2c Radeon i2c bit bus MONID I2C adapter i2c-4 i2c Radeon i2c bit bus GPIOPAD_MASK I2C adapter package contains also script called ddcmon that probes busses on given address, defaulting to 0x50, for something that looks like eeprom and contains data that can be interpreted as EDID block. running it with default arguments, i got VGA monitor's EDID on default addres on bus 3. scanning busses 1-4 for addresses 1-4096 (does it even make sense? ;-) ) gave no other hits. and now, i've disconnected VGA, leaving only DVI, and the same - bus 3 address 0x50 contains VGA's EDID. after reboot with only DVI connected, theres no EDIDs found anywhere. then, hw_i2c option of radeon module. got one more bus: i2c-0 smbus SMBus PIIX4 adapter at 0b00 SMBus adapter i2c-1 i2c Radeon i2c hw bus DVI_DDC I2C adapter i2c-2 i2c Radeon i2c hw bus VGA_DDC I2C adapter i2c-3 i2c Radeon i2c hw bus MM_I2CI2C adapter i2c-4 i2c Radeon i2c bit bus MONIDI2C adapter i2c-5 i2c Radeon i2c bit bus GPIOPAD_MASK I2C adapter edid of VGA is on 4th bus, 0x50 address - so standard one. after disabling drm modesetting (no X running) , DVI remained active. but no i2c busses :-/ get-edid from read-edid package managed to get proper edid (only one - even with 2 monitors connected) but using interrupt call: Read EDID Performing real mode VBE call Interrupt 0x10 ax=0x4f15 bx=0x1 cx=0x0 Function supported Call successful concluding: i have no idea where from get DVI edid after kms kicks in :-( ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
Re: No DVI output on ATI Xpress 200 - reopen
On Mon, Jul 23, 2012 at 6:29 PM, Przemysław Tomczyk tomczyk.prze...@gmail.com wrote: so. the box has 2 monitors (different) connected, thru VGA and DVI-D after inserting i2c-dev and eeprom modules, i've run i2cdetect from debian's i2c-tools package. output was: i2c-0 smbus SMBus PIIX4 adapter at 0b00 SMBus adapter i2c-1 i2c Radeon i2c bit bus DVI_DDC I2C adapter i2c-2 i2c Radeon i2c bit bus VGA_DDC I2C adapter i2c-3 i2c Radeon i2c bit bus MONID I2C adapter i2c-4 i2c Radeon i2c bit bus GPIOPAD_MASK I2C adapter package contains also script called ddcmon that probes busses on given address, defaulting to 0x50, for something that looks like eeprom and contains data that can be interpreted as EDID block. running it with default arguments, i got VGA monitor's EDID on default addres on bus 3. scanning busses 1-4 for addresses 1-4096 (does it even make sense? ;-) ) gave no other hits. and now, i've disconnected VGA, leaving only DVI, and the same - bus 3 address 0x50 contains VGA's EDID. after reboot with only DVI connected, theres no EDIDs found anywhere. then, hw_i2c option of radeon module. got one more bus: i2c-0 smbus SMBus PIIX4 adapter at 0b00 SMBus adapter i2c-1 i2c Radeon i2c hw bus DVI_DDC I2C adapter i2c-2 i2c Radeon i2c hw bus VGA_DDC I2C adapter i2c-3 i2c Radeon i2c hw bus MM_I2CI2C adapter i2c-4 i2c Radeon i2c bit bus MONIDI2C adapter i2c-5 i2c Radeon i2c bit bus GPIOPAD_MASK I2C adapter edid of VGA is on 4th bus, 0x50 address - so standard one. after disabling drm modesetting (no X running) , DVI remained active. but no i2c busses :-/ get-edid from read-edid package managed to get proper edid (only one - even with 2 monitors connected) but using interrupt call: Read EDID Performing real mode VBE call Interrupt 0x10 ax=0x4f15 bx=0x1 cx=0x0 Function supported Call successful concluding: i have no idea where from get DVI edid after kms kicks in :-( The vbios indicates it should use the gpio pad i2c setup in the i2c table for DVI ddc (GPIOPAD_MASK i2c bus), but it's possible the oem wired it up to something else. You could use something like the hacked up libx86 in the following package (http://people.freedesktop.org/~airlied/xresprobe-mjg59-0.4.21.tar.gz) to snoop what the vbe ddc implementation is doing when you use read_edid to read the EDID via vbe. You should be able to look at the register stream and see what gpio register and bits it is using. Once you find out, I can help you add support to the driver. Alex ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
[Bug 35457] [rs690m] Graphics corruption with ati x1200
https://bugs.freedesktop.org/show_bug.cgi?id=35457 --- Comment #45 from Carl c...@finknetwork.com 2012-07-24 01:58:45 UTC --- Replying to #44: I know that RadeonHD is not compatible with the current version. Thus my suggestion it be revived as a project. If it were compatible I'd just compile it. I'm short of time these days. Rather than making huge efforts to have X.Org fix the bug, I'll just remove the Debian partition from my netbook. Windows 7 works fine -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ xorg-driver-ati mailing list xorg-driver-ati@lists.x.org http://lists.x.org/mailman/listinfo/xorg-driver-ati
