[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=xorg&component=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=1&sort=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 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
