Re: rRadeon 9000 + X.Org 1.11.2 + EnablePageFlip + opengl = crash
On Die, 2011-12-06 at 17:44 -0500, Alex Deucher wrote: > On Tue, Dec 6, 2011 at 5:04 PM, Giuliano Pochini wrote: > > > > I also tried KMS. When EnablePageFlip is enabled glxgears renders nothing > > and X freezes immediately except the mouse pointer. After a few second the > > screen blanks and a reboot is the only cure. > > > > W/o EnablePageFlip it works better. glxgears looks OK, but it runs at > > 60fps. xterm colours are wrong. Wrong xterm colours would be an xf86-video-ati issue. > > Everything else seems fine. Running other 3D apps (Nexuiz, > > Scorched3D) works fine at first, but seconds or minutes later it > > locks up the same way without any symptom before that moment. > > With KMS apps are synced the refresh rate by default, you can > override that by setting the env var vblank_mode=0, e.g., > vblank_mode=0 glxgears > > Pageflipping with KMS works fine here, so it may be something mac specific. It works fine on this PowerBook with an RV350, but glxgears can't really use page flipping anyway with KMS, unless you run it in fullscreen mode maybe. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Strange problem that might be a hardware malfunction.
On Fre, 2011-11-11 at 04:00 -0700, James Richard Tyrer wrote: > On 11/11/2011 03:07 AM, Michel Dänzer wrote: > > On Don, 2011-11-10 at 21:34 -0700, James Richard Tyrer wrote: > >> I am using the "radeon" driver: xf86-video-ati-6.12.4 and Linux 3.0.4 > >> with X.Org 1.7.1. All 32 bit. > > Please provide the Xorg.0.log file and dmesg output. > > > Files are attached. Thanks, but please always follow up to the mailing list. I'm doing so now. Anyway, I can see a few problems: * X uses the generic vesa driver. Try the radeon driver instead. * The kernel is configured to use radeonfb, which precludes the radeon driver from enabling KMS. This may work, but it's generally recommended to disable radeonfb and enable KMS. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Strange problem that might be a hardware malfunction.
On Don, 2011-11-10 at 21:34 -0700, James Richard Tyrer wrote: > > I am using the "radeon" driver: xf86-video-ati-6.12.4 and Linux 3.0.4 > with X.Org 1.7.1. All 32 bit. Please provide the Xorg.0.log file and dmesg output. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
[ANNOUNCE] xf86-video-ati 6.14.3
I'm pleased to announce the 6.14.3 release of the xf86-video-ati (radeon) driver. Thanks to everybody who contributed! Highlights: * Support for more cards, in particular Llano APUs. * KMS page flipping fixes. * vdpau/XvMC support (currently only available for >= R3xx via Gallium3D). * Tiling fixes, enable it on more cards by default. Changes since 6.14.2: Alex Deucher (14): radeon: add support for llano APUs radeon: add llano pci ids kms: enable ColorTiling by default on r6xx-cayman asics kms/man: update ColorTiling info dri2/eg+: fix size and alignment of depth/stencil buffers dri2: missing bit from a6154c00c64932332e8f6e334661ffd579cfd894 dri2: fix copy pasto in a6154c00c64932332e8f6e334661ffd579cfd894 evergreen: fix num_banks for 2D tiling config radeon: add some new NI pci ids kms: fix possible leak in pageflip code r5xx+: Fix vline setup with crtc offsets update man page with new marking names man: note that the list of marketing names is non-exhaustive UMS: fix DDIA enable on some rs690 systems Christian König (1): Register XvMC video decoding acceleration Dave Airlie (2): bump version after release evergreen: Emit SQ_LDS_RESOURCE_MGMT Jeremy Huddleston (2): Use malloc/calloc/realloc/free directly Build fix for -Werror=int-to-pointer-cast Jerome Glisse (1): radeon/kms: fallback to vesa if GPU is not supported by UMS Maarten Lankhorst (1): dri2: Add vdpau driver name entry Michel Dänzer (12): Prefer the CRTC of the primary output for synchronization. Change my e-mail address to something that still works, and always will, I hope. video: Don't round up bottom/right edge for clipping source width/height. Bail if we're trying to start up in UMS mode on KMS. Convert register ranges for >= r6xx from enums to defines. KMS Color Tiling requires xserver which supports EXA_MIXED_PIXMAPS. Remove dead variable remain_size_bytes. Only call radeon_dri2_close_screen() if DRI2 was enabled. Make radeon_dri2_create_buffer(s) more robust. (Bug #30047) EXA < R6xx: Make sure 2D state is re-emitted after running out of CS space. EXA >= R6xx / KMS: Avoid running out of CS space at inconvenient times. Bump version for 6.14.3 release. Tormod Volden (1): radeon: do not include xf86PciInfo.h Ville Syrjala (2): dri2: Update front buffer pixmap and name before exchanging buffers kms: Move flip_count and co. to a per swap structure git tag: xf86-video-ati-6.14.3 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-ati-6.14.3.tar.bz2 MD5: 19126c8421a05d9605883dcf7498d876 xf86-video-ati-6.14.3.tar.bz2 SHA1: db635e2e2858d5db90362f546ac0adad85474bad xf86-video-ati-6.14.3.tar.bz2 SHA256: 844a2649eff6a3e92aff3e1837ea864f1561b4822b3e5d5ccb27b3b7fb8137b4 xf86-video-ati-6.14.3.tar.bz2 http://xorg.freedesktop.org/archive/individual/driver/xf86-video-ati-6.14.3.tar.gz MD5: c5e9ebdf3f68349eb68d72c170888325 xf86-video-ati-6.14.3.tar.gz SHA1: 9d13845e192108f41cb536d03e9e9bf8685ec7a2 xf86-video-ati-6.14.3.tar.gz SHA256: 12be0ec960f2d700fd259ab5eec2a1c7a0564ec7fa057502a3457ca4e97ad334 xf86-video-ati-6.14.3.tar.gz -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer signature.asc Description: This is a digitally signed message part ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: radeon - no video after leaving X
On Mit, 2011-10-12 at 10:08 +0200, jarek wrote: > > I have installed Xorg (version 7.6) with radeon driver. It works fine, > but there is no video in text console After Ctrl+Alt+F1 monitors goes > off. Also after exit from X there is no video - system is still > operational, I can blindly start X again. > Before X text console works fine. [...] > [ 267.157] (II) [KMS] drm report modesetting isn't supported. Are you intentionally disabling KMS? If not, does it work better with KMS enabled (e.g. via radeon.modeset=1 on the kernel command line, and making sure the radeon kernel module is loaded before X starts)? -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Backing Store not working in 8 Bit color depth with vesa driver
On Mon, 2011-09-19 at 12:52 -0400, James Cloos wrote: > IIRC, the current server code requires that one use a compositing > manager to do backing store. > > It has beena while since this last come up, though. I may be mis- > remembering. You are. Backing store was rewritten to use the composite layer, but that doesn't require a compositing manager. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Issues running Xorg in 8 bit color mode:q
On Fre, 2011-09-16 at 07:44 -0500, Doug Kuvaas wrote: > 2011/9/16 Michel Dänzer > On Don, 2011-09-15 at 14:26 -0500, Doug Kuvaas wrote: > > I have a legacy application that is run from a UNIX host > computer that > > does not function properly if executed with color depths > greater than > > 8 bits. When I try to run Xorg in the form of Xorg :0 +bs > -wm -retro > > -depth 8 -fbbpp 8, all I end up with is grayscale, no color > at all. > > > See > http://lists.x.org/archives/xorg-devel/2011-January/018452.html . A > sad example of perfect being the enemy of better... > > Does this mean that want I want to do is no longer supported by Xorg? > Or do I need to build a more recent version? RandR isn't needed by my > application, so that can certainly be left out if need be I'm afraid that doesn't matter. Until it's fixed in the X server, the options I see for you are basically: * Hack the video driver you use not to set the gamma_set member of xf86CrtcFuncsRec. * Use a driver that doesn't support RandR 1.2 or newer, e.g. fbdev or vesa. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Issues running Xorg in 8 bit color mode:q
On Don, 2011-09-15 at 14:26 -0500, Doug Kuvaas wrote: > I have a legacy application that is run from a UNIX host computer that > does not function properly if executed with color depths greater than > 8 bits. When I try to run Xorg in the form of Xorg :0 +bs -wm -retro > -depth 8 -fbbpp 8, all I end up with is grayscale, no color at all. See http://lists.x.org/archives/xorg-devel/2011-January/018452.html . A sad example of perfect being the enemy of better... -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: poor video playback performace with radeon
On Mon, 2011-09-05 at 15:37 +0300, Taneli Vähäkangas wrote: > On Sun, Sep 04, 2011 at 11:44:44PM +0300, Taneli Vähäkangas wrote: > > I made some changes that make it not fail for I and P pictures (B > > pictures still fail that assertion). After the changes, the video > > I noticed that the problem is (likely) not in the frame type > (I/P/B). Many videos, even commercial DVD titles, seem to have > mistakes in the bitstream. For example the default mplayer codec > will complain "ac-tex damaged" (or something similar). If such a > situation is detected, what should be done in > vl_mpeg12_bitstream.c? You should probably discuss this on the mesa-dev mailing list, and make sure Christian König sees it. I suspect he doesn't read this list. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: xscreensaver triggers X server to crash
On Die, 2011-08-09 at 12:10 +0300, Janne Huttunen wrote: > > Does the xserver patch below help? > > That was fast :-) Thanks for your detailed analysis of the problem. > With the limited testing (lock/unlock screen ~10 times) it looks very > good so far. With your patch I haven't been able to either crash X or > trigger the sanity-check log I originally added to detect the too > small malloc. Great, thanks for testing. I've submitted the patch for inclusion. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Debian, X and DRI developer ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: xscreensaver triggers X server to crash
On Die, 2011-08-09 at 10:55 +0300, Janne Huttunen wrote:
> Hi!
>
> I have a highly repeatable use-case, where xscreensaver causes the X server to
> crash. To be exact, it doesn't seem to be the screensaver itself, but the
> unlock
> dialog it shows when it is deactivated. The crash itself is actually a SIGABRT
> raised by malloc() due to corrupted memory.
>
> The memory corruption seems to happen like this:
>
> ==7560== Invalid write of size 8
> ==7560==at 0x4C2A22E: memcpy (mc_replace_strmem.c:635)
> ==7560==by 0x8BF8FF6: RADEONDownloadFromScreenCS (radeon_exa_funcs.c:667)
> ==7560==by 0x989DE6E: exaCopyDirty (exa_migration_classic.c:220)
> ==7560==by 0x98A0B01: exaPrepareAccessReg_mixed
> (exa_migration_mixed.c:247)
> ==7560==by 0x98AB318: ExaCheckPolyGlyphBlt (exa_unaccel.c:342)
> ==7560==by 0x4C4589: damageText (damage.c:1489)
> ==7560==by 0x4C86C2: damagePolyText8 (damage.c:1507)
> ==7560==by 0x444824: doPolyText (dixfonts.c:1368)
> ==7560==by 0x4457B8: PolyText (dixfonts.c:1437)
> ==7560==by 0x435328: ProcPolyText (dispatch.c:2260)
> ==7560==by 0x437EE8: Dispatch (dispatch.c:431)
> ==7560==by 0x421A7D: main (main.c:287)
> ==7560== Address 0x113b1040 is 0 bytes after a block of size 4,915,200
> alloc'd
> ==7560==at 0x4C28FAC: malloc (vg_replace_malloc.c:236)
> ==7560==by 0x98A0B43: exaPrepareAccessReg_mixed
> (exa_migration_mixed.c:203)
> ==7560==by 0x98AB318: ExaCheckPolyGlyphBlt (exa_unaccel.c:342)
> ==7560==by 0x4C4589: damageText (damage.c:1489)
> ==7560==by 0x4C86C2: damagePolyText8 (damage.c:1507)
> ==7560==by 0x444824: doPolyText (dixfonts.c:1368)
> ==7560==by 0x4457B8: PolyText (dixfonts.c:1437)
> ==7560==by 0x435328: ProcPolyText (dispatch.c:2260)
> ==7560==by 0x437EE8: Dispatch (dispatch.c:431)
> ==7560==by 0x421A7D: main (main.c:287)
>
> As far as I can tell, the reason seems to be that when the system buffer is
> allocated in exaPrepareAccessReg_mixed, for some reason the pixmap
> width is 1600 (the width of my display) and bpp is 32, but sys_pitch is only
> 4096. The allocated buffer won't then be big enough for the data and
> the memcpy ends up overwriting some adjacent data structure.
>
> Do you have any idea whether this has already been corrected in
> a newer version, or if it isn't what other information should I provide
> to help finding and solving the problem?
>
> I am currently running Ubuntu 11.04 on x86_64 with the vendor
> provided kernel and Xorg packages:
>
> linux-image-2.6.38-10-generic 2.6.38-10.46
> xserver-xorg-core 2:1.10.1-1ubuntu1.1
> xserver-xorg-video-radeon 1:6.14.0-0ubuntu4.1
Does the xserver patch below help?
diff --git a/exa/exa_mixed.c b/exa/exa_mixed.c
index fd1afb2..ff9f30e 100644
--- a/exa/exa_mixed.c
+++ b/exa/exa_mixed.c
@@ -185,11 +185,12 @@ exaModifyPixmapHeader_mixed(PixmapPtr pPixmap, int width,
int height, int depth,
RegionEmpty(&pExaPixmap->validFB);
}
+ pExaPixmap->sys_pitch = PixmapBytePad(width, depth);
+
/* Need to re-create system copy if there's also a GPU copy */
if (has_gpu_copy && pExaPixmap->sys_ptr) {
free(pExaPixmap->sys_ptr);
pExaPixmap->sys_ptr = NULL;
- pExaPixmap->sys_pitch = PixmapBytePad(width, depth);
DamageUnregister(&pPixmap->drawable, pExaPixmap->pDamage);
DamageDestroy(pExaPixmap->pDamage);
pExaPixmap->pDamage = NULL;
--
Earthling Michel Dänzer | http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com
Re: Slow 2D Graphics - IBM T60p - Ubuntu 10.10
On Fre, 2011-07-01 at 11:14 -0700, James Rollins wrote:
> The only real problem is terrible 2D performance in some applications:
> - VNC sessions (through Vinagre and through other VNC clients)
> - Cadence Virtuoso XL Layout (an integrated circuit CAD application)
>- YouTube (flash) videos
>
> The big ones for me are VNC and Cadence, as these are the tools I use
> for work. If I dual-boot into Windows XP and use VNC the speed is
> fine. Note that Youtube (flash) videos are fine in XP as well.
Please provide your full /var/log/Xorg.0.log file and maybe also the
dmesg output, at least the parts relating to the drm/radeon drivers.
P.S. HTML e-mail is generally frowned upon on this mailing list.
--
Earthling Michel Dänzer |
http://www.amd.com
Libre software enthusiast | Debian, X and DRI developer
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com
Re: Xorg R7.6 mesa/egl Makefile fixing in Ubuntu 10.10
On Mon, 2011-02-21 at 16:05 +0800, Chen, Dennis (SRDC SW) wrote: > Hi All, > > > > I found that current the Makefile of mesa/mesa/src/egl/main in X11 > R7.6 has the below line: > > > > INCLUDE_DIRS = -I$(TOP)/include > > > > When build the mesa module in Ubuntu system, this will led to a build > error complaining “can’t find the X11/Xlib.h”, that’s because in > ubuntu, the Xlib.h is located in /usr/include/X11 by default, so I > think > > The Makefile should be changed to: > > > > INCLUDE_DIRS = -I$(TOP)/include -I/usr/include/X11 Please send a patch (preferably generated by git format-patch) to the mesa-dev mailing list at lists.freedesktop.org . -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Video Window is always on top
On Mon, 2011-02-07 at 14:44 +0530, vishnu jagadish wrote: > > We ported angstrom in Devkit8000 & using Metacity Window Manager with > Kernel Linux-2.6.38-rc1+. USB,video,audio,etc.. functionalities are > working well. We have problem of swapping video window with other > window in the screen. > > When windows with non-video is getting swapped well. But in case any > of the window have the video then, only the border part of video > window is going back but the video is still visible at the > foreground. Without more information, my first guess would be that compositing is enabled in Metacity, and that the driver uses xf86XVFillKeyHelper() but should be using xf86XVFillKeyHelperDrawable() instead. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: system locks when exiting X with radeon driver
On Mon, 2011-01-31 at 04:46 -0400, Joseph Mingrone wrote: > I'm running the latest xorg (7,5) compiled from ports on FreeBSD 8.2 > RC2 and everything is working fine, but when I shutdown X, the system > locks every time. This happens when I start X with no configuration > file or the configuration file below with either the ati or radeon > driver. If I switch to the vesa driver the problem stops, but of > course performance drops (scrolling text, windows, etc. lag). > > The relevant lines ffom pciconf -lv are > > [CODE]vgapci0@pci0:1:0:0: class=0x03 card=0x17721043 > chip=0x4e501002 rev=0x00 hdr=0x00 > vendor = 'ATI Technologies Inc. / Advanced Micro Devices, Inc.' > device = 'ATI MOBILITY /ATI RADEON 9600/9700 Series (M10)' > class = display > subclass = VGA[/CODE] > > [URL="http://pastebin.com/my0zgUmX"]Xorg.0.log when using no > configuration file[/URL] > [URL="http://pastebin.com/0YMaAnZn"]Xorg.0.log when using the > configure file below[/URL] > [URL="http://pastebin.com/rTEX8b5g"]xorg.conf[/URL] Please attach files directly rather than referencing external resources, particularly volatile ones such as pastebins. > I've seen similar posts, which suggestion disabling dri, setting > various values for AccelMethod, setting different values for AGPMode > or using Option"BusType" "PCI". I've tried all these, bu they > don't solve the problem. > > Any suggestions? Not sure what to suggest other than trying a current Git snapshot of the driver. Please elaborate a bit on what exactly 'the system locks' means though. Does it not even respond to ping? Or if it does, can you log in via ssh? ... -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: [Openchrome-devel] VIA VX900 IGP doc released
On Sam, 2011-01-22 at 01:36 +0100, Xavier Bachelot wrote: > On 01/21/2011 08:03 PM, Pat Kane wrote: > > I see that the "openchrome-devel" list hates me, it just sent > > me this unfriendly reply: > > > > You are not allowed to post to this mailing list, and your message has > > been automatically rejected. If you think that your messages are > > being rejected in error, contact the mailing list owner at > > openchrome-devel-ow...@openchrome.org. > > > > Which part of "open" do they not get? > > > You need to be subscribed to post to this list. Automatically rejecting posts from non-subscribers is rather rude though. They can be handled via the moderation queue without much effort. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: BLack Screen while running X11 on /dev/fb1
On Die, 2010-12-14 at 12:31 +0530, umang gupta wrote: > > I planned to run my X11 on 2nd framebuffer device /dev/fb1 in place > of fb0 . I have enabled both nodes in kernel and hence I have /dev/fb0 > and /dev/fb1 on board . > I created a conf file 22-xorg-fb1.conf > in /etc/X11/xorg.conf.d/ ..that I am attaching here . > > When I started X by running startx , I get a black screen . . I got > logs as Xfb1.log . > > Now I replace conf file with 22-xorg-fb0.conf that access fb0 .. I got > X11 seen on screen . Logs received as Xfb0.log .. > > Now I kill X , again uses /dev/fb1 , run startx , it brings X11 > up ... > > > I am not getting why , while using fb1 first time , I am getting > black screen ? Is there any difference in Xorg.0.log or the output of fbset -i -fb /dev/fb1 between the unsuccessful and successful attempts, or does something appear in the dmesg output between them? ... -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Xorg segfaults after upgrade of Fedora Core 13->14
On Mit, 2010-11-17 at 13:59 -0500, Mathew Hennessy wrote: > Hi, > I'm getting periodic Xorg segfaults after upgrading from FC13 to FC14 > on i686.. Here's what it left as a backtrace in Xorg.0.log.old: > > [ 81396.084] > Backtrace: > [ 81396.103] 0: /usr/bin/Xorg (xorg_backtrace+0x39) [0x80c6ea1] > [ 81396.103] 1: /usr/bin/Xorg (0x8048000+0x4dbb7) [0x8095bb7] > [ 81396.103] 2: (vdso) (__kernel_rt_sigreturn+0x0) [0xa1940c] > [ 81396.103] 3: /usr/bin/Xorg (doListFontsWithInfo+0xb6) [0x806ca74] > [ 81396.103] 4: /usr/bin/Xorg (ProcessWorkQueue+0x28) [0x806f93c] > [ 81396.103] 5: /usr/bin/Xorg (WaitForSomething+0x48) [0x80906c6] > [ 81396.103] 6: /usr/bin/Xorg (0x8048000+0x2404f) [0x806c04f] > [ 81396.103] 7: /usr/bin/Xorg (0x8048000+0x1a434) [0x8062434] > [ 81396.103] 8: /lib/libc.so.6 (__libc_start_main+0xe6) [0x6e0e16] > [ 81396.103] 9: /usr/bin/Xorg (0x8048000+0x19f61) [0x8061f61] > [ 81396.103] Segmentation fault at address (nil) Looks like https://bugs.freedesktop.org/show_bug.cgi?id=31675 FWIW. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Reasons for FreePicture to cause "RenderBadPicture"?
On Fre, 2010-08-27 at 21:43 +0200, Clemens Eisserer wrote: > Hi again, > > Seems I have found the cause of the problem: Freeing Pictures that > belong to an already destroyed window cause the RenderBadPicture > error. The XID values in the error-log were wrong and therefor > misleading. > > What puzzles me is the inconsistent behaviour: > When a Window is destroyed, all its associated Pictures are freed, > however this is not the case for Pixmaps. > Even after calling XFreePixmap the assiciated Picture-Objects stay alive. Pixmaps are reference-counted and the picture takes a reference on the pixmap, so the pixmap can't go away before the picture. However this isn't true for windows, so as soon as the window is destroyed presumably the picture is destroyed as well or becomes invalid. If you can't avoid using window pictures, it's probably best to make sure you destroy any pictures before the windows themselves. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Problem with xorg-server and s3c2410fb driver
On Mon, 2010-08-02 at 13:56 -0400, Adam Jackson wrote: > On Mon, 2010-08-02 at 18:24 +0200, Michel Dänzer wrote: > > > AFAICT this will only work when using the 'built-in' mode, otherwise > > mode->PrivFlags will never be set? One possible solution for that could > > be > > > > - var->pixclock = mode->Clock ? 10/mode->Clock : 0; > > + var->pixclock = mode->PrivFlags ? mode->PrivFlags : > > (mode->Clock ? 10/mode->Clock : 0); > > > > in xfree2fbdev_timing(). > > Right you are. > > So I guess the question is what we're trying to accomplish with the > fbdev_modes_equal() check at all. From commit f6815cb68b0f6698497348fc6e4214dacef33b95 which added it: The fbdev API allows the driver to 'accept' modes it doesn't really support by modifying it to the nearest supported mode. Without this check, e.g. vesafb would appear to accept all modes, even though it actually can't set any modes other than the bootup mode at all. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Problem with xorg-server and s3c2410fb driver
On Mon, 2010-08-02 at 11:51 -0400, Adam Jackson wrote:
> On Mon, 2010-08-02 at 15:59 +0200, Michel Dänzer wrote:
> > On Son, 2010-07-25 at 09:35 +0300, Vasily Khoruzhick wrote:
> > > Hi,
> > >
> > > I'm trying to get xorg-server + xf86-video-fbdev working on my device,
> > > and I'm
> > > hitting problem:
> > >
> > > pixclock value of fb mode on my device is 26 picosecs, and due to
> > > picosecs
> > > <-> khz conversions in xorg-server I'm getting rounding error:
> > >
> > > 10 / 26 = 3846
> > > 10 / 3846 = 260010
> > >
> > > (Look through xfree2fbdev_timing and fbdev2xfree_timing functions in
> > > fbdevhw.c
> > > for more details)
> > >
> > > xorg-server gets mode via FBOIGET_VSCREENINFO (pixclock = 26),
> > > converts it
> > > to its own format, then converts it back to fbmode (due to rounding error
> > > pixclock - 260010) and then tries to set mode with pixvalue 260010 via
> > > FBIOPUT_VSCREENINFO ioctl, but driver sets it back to 26, and
> > > xorg-server
> > > fails to startup with this message:
> > >
> > > (EE) FBDEV(0): FBIOPUT_VSCREENINFO succeeded but modified mode.
> >
> > What version of xserver are you using? It sounds like your problem
> > should be fixed by Git commit bf333c2f9833a178887e7bdd7fc338f1e09c387f
> > ('fbdevhw: Remove pixclock check.') which should be included since 1.6.x
> > at least.
>
> bf333c2 is kind of gross. Seems like the right thing is to revert it
> and then apply:
>
> --
> From: Adam Jackson
> Date: Mon, 2 Aug 2010 11:48:22 -0400
> Subject: [PATCH] fbdevhw: Avoid rounding error from psec/kHz conversion
>
> Stash the real fbdev clock in mode->PrivFlags and use that for actual
> mode set calls. ->Clock is then only used for display in the log.
>
> Signed-off-by: Adam Jackson
> ---
> hw/xfree86/fbdevhw/fbdevhw.c |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/hw/xfree86/fbdevhw/fbdevhw.c b/hw/xfree86/fbdevhw/fbdevhw.c
> index f160908..3a6df94 100644
> --- a/hw/xfree86/fbdevhw/fbdevhw.c
> +++ b/hw/xfree86/fbdevhw/fbdevhw.c
> @@ -201,7 +201,7 @@ xfree2fbdev_timing(DisplayModePtr mode, struct
> fb_var_screeninfo *var)
> if (var->yres_virtual < var->yres)
> var->yres_virtual = var->yres;
> var->xoffset = var->yoffset = 0;
> - var->pixclock = mode->Clock ? 10/mode->Clock : 0;
> + var->pixclock = mode->PrivFlags;
> var->right_margin = mode->HSyncStart-mode->HDisplay;
> var->hsync_len = mode->HSyncEnd-mode->HSyncStart;
> var->left_margin = mode->HTotal-mode->HSyncEnd;
> @@ -267,6 +267,7 @@ fbdev2xfree_timing(struct fb_var_screeninfo *var,
> DisplayModePtr mode)
> else if ((var->vmode & FB_VMODE_MASK) == FB_VMODE_DOUBLE)
> mode->Flags |= V_DBLSCAN;
> mode->SynthClock = mode->Clock;
> + mode->PrivFlags = var->pixclock;
> mode->CrtcHDisplay = mode->HDisplay;
> mode->CrtcHSyncStart = mode->HSyncStart;
> mode->CrtcHSyncEnd = mode->HSyncEnd;
AFAICT this will only work when using the 'built-in' mode, otherwise
mode->PrivFlags will never be set? One possible solution for that could
be
- var->pixclock = mode->Clock ? 10/mode->Clock : 0;
+ var->pixclock = mode->PrivFlags ? mode->PrivFlags :
(mode->Clock ? 10/mode->Clock : 0);
in xfree2fbdev_timing().
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com
Re: Problem with xorg-server and s3c2410fb driver
On Son, 2010-07-25 at 09:35 +0300, Vasily Khoruzhick wrote:
> Hi,
>
> I'm trying to get xorg-server + xf86-video-fbdev working on my device, and
> I'm
> hitting problem:
>
> pixclock value of fb mode on my device is 26 picosecs, and due to
> picosecs
> <-> khz conversions in xorg-server I'm getting rounding error:
>
> 10 / 26 = 3846
> 10 / 3846 = 260010
>
> (Look through xfree2fbdev_timing and fbdev2xfree_timing functions in fbdevhw.c
> for more details)
>
> xorg-server gets mode via FBOIGET_VSCREENINFO (pixclock = 26), converts
> it
> to its own format, then converts it back to fbmode (due to rounding error
> pixclock - 260010) and then tries to set mode with pixvalue 260010 via
> FBIOPUT_VSCREENINFO ioctl, but driver sets it back to 26, and xorg-server
> fails to startup with this message:
>
> (EE) FBDEV(0): FBIOPUT_VSCREENINFO succeeded but modified mode.
What version of xserver are you using? It sounds like your problem
should be fixed by Git commit bf333c2f9833a178887e7bdd7fc338f1e09c387f
('fbdevhw: Remove pixclock check.') which should be included since 1.6.x
at least.
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
___
xorg@lists.freedesktop.org: X.Org support
Archives: http://lists.freedesktop.org/archives/xorg
Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Your subscription address: arch...@mail-archive.com
Re: EXA classic problem with Xv
On Fre, 2010-07-23 at 14:30 +0200, Yves De Muyter wrote: > Sorry I misread your suggestion. No worries, my bad for using double negation. > I now pass NULL as second argument to fbScreenInit(). Driver seems to > work fine on non-Xv stuff so that seems fine. > > I'm not so sure the current issue is still with the pixmap being pinned > nor that it is the screen pixmap. The fb_ptr on the pixmap is still > NULL, the sys_ptr isn't, so I guess the pixmap is offscreen and I need > to move/force it onscreen somehow ? exaMoveInPixmap() doesn't work since > that one skips its functionality if EXA_OFFSCREEN_PIXMAPS is set [...] I'm afraid you read the logic there the wrong way again. > Also to note, sys_ptr=0xb6c1c000 and memoryBase=0xb4a74000. memoryBase is irrelevant for the mixed scheme as all GPU accessible pixmap memory is allocated by the driver via the CreatePixmap(2) hook. > Any Idea how I can access the framebuffer address of the pixmap from > within the driver? The driver should have allocated the pixmap memory, so it should know how to access it - e.g. the same way it's done in the driver PrepareAccess hook should work. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: EXA classic problem with Xv
On Fre, 2010-07-23 at 12:07 +0200, Yves De Muyter wrote: > Second argument of fbScreenInit() is definitely not NULL but points to > the framebuffer address like it should. Again, you need to pass NULL to prevent the screen pixmap from being pinned in system memory. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: EXA classic problem with Xv
On Don, 2010-07-22 at 20:18 +0200, Yves De Muyter wrote: > > I have now ported the driver to exa_mixed (also because the > exa_classic bugfix is not being backported to 1.7 and this way we > bypass the issue). > > Driver seems to work fine, just like it did under exa_classic. > > But the same issue remains, mplayer and others still use the > fullscreen pixmap as a Xv pixmap and that one is 'pinned'. It shouldn't be, make sure you don't pass a non-NULL second argument to fbScreenInit(). -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: exaModifyPixmapHeader_mixed on screen pixmap
On Don, 2010-07-22 at 10:22 +0800, fly fancy wrote: > In exaModifyPixmapHeader_mixed, when pPixData is not NULL, > it'll destroy driver private of the pixmap and set the pixmap pinned > and non-offscreen. So, how about screen pixmap creation? Screen pixmap > will be set to unaccelerable according to this implementation of > exaModifyPixmapHeader_mixed. But this is not reasonable. Can someone > help? Thanks! AFAICT the trick is to pass NULL as the second argument to fbScreenInit(). -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: EXA classic problem with Xv
On Don, 2010-06-10 at 12:54 +0200, Yves De Muyter wrote: > Here you find the code: > > http://code.google.com/p/gma500/source/browse/trunk/xserver-xorg-video-psb/xserver-xorg-video-psb-0.32.1/src/psb_video.c > > The problem is on line 688. > > The code tries to find the pointer to the buffer and the offset, and if > it doesnt find it, it calls exaMoveInPixmap(). > > I don't like the 'while' thing personally but I didn't write that code > and are willing to change it, that's not the problem. FWIW I don't think it makes sense to try exaMoveInPixmap more than once. > The problem is that exaMoveInPixmap() doesnt do anything if the pixmap > has a score that is 'PINNED', and that's the case here... As the pixmap was retrieved from a window, I *think* the only way it can be pinned is if it's the screen pixmap (i.e. you're not using a compositing manager, or it unredirected the fullscreen window). In that case I think the problem is actually a spurious failure of psbExaGetSuperOffset(), possibly due to an issue in exaGetPixmapOffset() - there's recently been some discussion about that with drivers like psb or geode. Of course these issues should be fixed, but in the long term it might make sense for the psb driver to use the EXA 'mixed' or 'driver' pixmap memory allocation scheme rather than the 'classic' one in rather special ways prone to breakage. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: EXA classic problem with Xv
On Don, 2010-06-10 at 12:34 +0200, Yves De Muyter wrote: > OK so i'm porting the 'poulsbo' driver to Xorg 1.7. What I'm working on > right now is to make Xv work in the driver. What the Xv-code does is to > get the address of the drawable, map it into SHM and ask the hardware to > blit the videoframe onto that drawable. > > The problem is that the address of the drawable is not within our region > of SHM pixmap memory, so we need to call exaMoveInPixmap, but that one > doesnt work when the pixmap is pinned... It would probably help if you could point to the code in question along with a specific example of a window being passed in and where exactly the problem arises. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: EXA classic problem with Xv
On Mit, 2010-06-09 at 22:18 +0200, Yves De Muyter wrote: > > I'm trying to port an older driver to XFree 1.7 and I'm facing an > issue with EXA (classic). It seems that Xv's "PutImage" is calling our > PutImage handler with a Drawable that is PINNED ? > > That means we cannot ever draw to it since exaMoveInPixmap() doesnt > work on pinned pixmaps... The drawable passed to the PutImage hook is up to the client, not the XVideo layer. Please provide more information about the problem. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
RE: The RandR-"unable to set rotation" issue in AMD Geode LX platform
On Mit, 2010-06-02 at 19:30 +0800, Cui, Hunk wrote: > > But I mean in the Xsever1.7.1 or Xserver1.8.99, the maskX and maskY > values are 0, this is why? Again, the actual mask coordinates don't (or at least shouldn't, i.e. the driver should ignore them in this case) matter because there's nothing to apply them to. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
RE: The RandR-"unable to set rotation" issue in AMD Geode LX platform
On Mit, 2010-06-02 at 19:15 +0800, Cui, Hunk wrote: > > #0 lx_do_composite (pxDst=0x8bef7f0, srcX=0, srcY=0, maskX=13860, > maskY=-1740, dstX=0, dstY=0, width=1024, height=768) at lx_exa.c:992 [...] > #4 CompositePicture (op=1 '\001', pSrc=0x8bb2fc0, pMask=0x0, pDst=0x8bb41c0, > xSrc=0, ySrc=0, xMask=, yMask=, > xDst=, yDst=, width=1024, > height=768) at picture.c:1675 [...] > The lx_do_composite function is the Geode-driver function, the others > are the XServer function, when I replace to the Xsever1.7.1 or > Xserver1.8.99, the maskX and maskY values are 0. That make me doubt > it. Can you have some other opinion? As there's no mask involved in the composite operation (pMask == NULL), the mask coordinates are irrelevant. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg Your subscription address: arch...@mail-archive.com
Re: Ati Radeon 7200 3D feature is buggy (kernel 2.6.34-rc6, ATI driver 6.13) (Answer TWO: more precise)
On Mon, 2010-05-03 at 21:50 +0200, Uwe Bugla wrote: > Am Montag, den 03.05.2010, 12:49 -0400 schrieb Alex Deucher: > > 2010/5/3 Uwe Bugla : > > > Am Montag, den 03.05.2010, 15:27 +0200 schrieb Michel Dänzer: > > >> On Sam, 2010-05-01 at 09:33 +0200, Uwe Bugla wrote: > > >> > Hi, > > >> > > > >> > I am working with an ATI Radeon 7200 QD (R100) on a Pentium 4 machine > > >> > with Intel AGP chipset. > > >> > The card driver is 6.13 (latest snapshot from April 30). > > >> > > > >> > To savely exclude other side effects I did the following: > > >> > Recompile mesa library 7.9 devel and libdrm 2.4.20 from snapshot of > > >> > April 30. > > >> > > > >> > What is the symptom? > > >> > Via config manager of Gnome 2.30 I make metacity a composite manager > > >> > for > > >> > a reduced > > >> > amount of 3D effects. > > >> > What happens with the ATI driver (NOT with the self-built nouveau > > >> > driver > > >> > running > > >> > with my Nvidia cards - this one works fantastic!) is the following: > > >> > > > >> > If I go to the Linux Kernel archives via iceweasel 3.59 and push the > > >> > right mouse > > >> > button over some "View Patch" entry I get a window throwing shadows, as > > >> > intended. > > >> > > > >> > BUT: The window does not contain any text! > > >> > I wonder if the 6.13 driver can deal with the fact that the card only > > >> > has 32 MB RAM. > > >> > But this is wild guessing, as I do not have any idea. > > >> > Maybe this hint / symptom is helpful for the developers. > > >> > > > >> > When publishing driver 6.13 you were promising a driver being able of > > >> > 3D > > >> > and 2D > > >> > effects plus KMS. > > >> > Except the 3D effects everything is working fine. > > >> > When will you finally fulfil that promise? > > >> > > >> Did you test the kernel patch I asked you to? > > > > > > > > > Hello everybody, > > > > > > SIGH! I got Compiz running together with my ATI Radeon QD 7200 (=R100). > > > > > > Just to make it clear for every one: > > > > > > Needed are: > > > > > > 1. Kernel 2.6.34-rc6 > > > 2. a self built Debian package containing the latest snapshot from > > > driver xf86-video-ati, version 6.13. > > > 3. one AGP patch > > > 4. one Radeon patch > > > 5. most important (and this one cost me hours to find out!): > > > > > > NOT the latest master from here: > > > http://cgit.freedesktop.org/mesa/mesa/ > > > This master contains hunks which make the whole thing incompatible! > > > > > > > What hunks are causing problems? What sort of problems are you seeing? > > > > > > > > > > > Instead you can use this one: > > > http://cgit.freedesktop.org/mesa/mesa/snapshot/mesa-nvfx-next-6b.tar.gz > > > > > > This is Luca Barbieri's experimental tree, which not only works > > > excellent with my Nvidia nv34 cards, but furthermore seems to be the > > > only one to work with my ATI driver.. > > > > > > > > > > > > Michel Dänzer does not like the Radeon patch, and Dave Airlie promised > > > to write a better one. > > > Unfortunately I haven't seen any patch from Dave yet, so the empty > > > promise stays to at least try to find a better solution.. > > > > There were several new variations of the patch from both Dave and > > Michel and you were cc'ed on most of them: > > http://marc.info/?l=dri-devel&m=127233579110506&w=2 > > http://lists.freedesktop.org/archives/dri-devel/2010-April/000266.html > > http://lists.freedesktop.org/archives/dri-devel/2010-April/000309.html > > > > Alex > > Hi all, > > 1. I was not consequently cc'ed. Yes, you were. > 2. I am not familiar with acronyms like bo or VRM > 3. I owe no subscription at the dri devel list. > 4. None of the 3 patches applies against 2.6.34-rc6 without further > overworking, and this work does not only cover line adjustment > 5. If I must adjust the line numbers of the patches to avoid fuzz > factors and line overhead that is OK so far. > 6. But if the patch does not compile after these adjustments that is > anything but healthy for the mood > 7. The Email header was changed, so I did not find Michel's approaches > in order to test them. > > Now let's have a closer look to the patches: > > Michel's contributions unfortunately neither apply as patch, nor do they > compile against kernel 2.6.34-rc6. > Result: Unusable. > > Dave's contribution contains a hunk 6 against radeon_object.c which is > pure crap, as radeon_object.c is simply not long enough: 509 lines! > > This is the piece of crap (i. e. hunk 6) which should not be there: [...] The only 'crap' I've seen has been your uttering. If you're trying to make our killfiles, you're doing pretty good. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: ATI Radeon R100 QD (7200) refuses to work with Compiz (Kernel 2.6.34-rc4)
On Die, 2010-04-27 at 08:19 +1000, Dave Airlie wrote: > 2010/4/26 Michel Dänzer : > > On Son, 2010-04-25 at 20:31 +1000, Dave Airlie wrote: > >> > >> I'm just going to separate the pinning code from the validate code wrt > >> domain->placement translation. > > > > That's a start, but IME validation using the new scheme degrades > > performance on setups which work with the old scheme. Maybe the old > > scheme can be tried first and the new one as a fallback, at least as an > > interim solution. But I think the new scheme really shouldn't be > > necessary if we didn't over-report the amount of VRAM available to > > userspace and prevented fragmentation due to pinned BOs, which should be > > feasible. > > I can't see why it would degrade anything, Not 100% sure but most likely because it disables the only mechanism we have to move BOs back into VRAM after having been evicted. Try running a session with compiz or so and slightly more BOs in total than can fit in VRAM. > currently it fails to work, I can't see us making fails to work into > something worse. If you think its working I can generate a non-working > workload quite trivally, its just luck it works at present. *I* am perfectly aware of the problem *you* are trying to fix, but I don't agree it justifies or requires any impact on working setups to solve. > The problem is its easy to say the words "prevent fragmentation due to > pinned BOs" its a lot messier to actually implement, > Look at fast user switch or front resize, in all cases we require both > the old pin and the new pin in VRAM at the same time, in order to make > a smooth transistion, we can't pin both of them at the sweet spots, so > one will always end up in the bad place. Now X makes this worse since > with an external monitor for some reason we create a front bo for a > cloned output and it gets resized later, so we always end up with a bo > pinned in the wrong place when a VGA monitor is plugged in. The option > of moving the BO in vblank might be possible, but it it happens more > than once it'll get really messy, and again fast user switch is going > to be a pain no matter what. Doing it in vblank shouldn't even be necessary as long as an overlap of the old and new BO location can be prevented. Anyway, I realize this will be non-trivial, which is why I suggested an interim solution. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xorg-server 1.8.0.901
On Die, 2010-04-27 at 15:14 +1000, Peter Hutterer wrote: > > Rest of the changes are all over the board but at this point I'd like to > remind everyone - if you want a patch in 1.8.1, please let me know to make > sure it doesn't get lost. I'm not picking up everything from master, > especially those areas I don't know too well are simply ignored by me. [...] > DRI2: Track DRI2 drawables as resources, not privates This change broke GLX compositing managers, see https://bugs.freedesktop.org/show_bug.cgi?id=27767 There's still no solution even on master. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: ATI Radeon R100 QD (7200) refuses to work with Compiz (Kernel 2.6.34-rc4)
On Son, 2010-04-25 at 20:31 +1000, Dave Airlie wrote: > 2010/4/25 Michel Dänzer : > > On Son, 2010-04-25 at 11:35 +0200, Uwe Bugla wrote: > >> Am Samstag, den 24.04.2010, 12:31 -0400 schrieb Alex Deucher: > >> > On Sat, Apr 24, 2010 at 11:48 AM, Chicken Shack > >> > wrote: > >> > > > >> > > 1. The real issue of that Compiz problem IS NOT what dmesg says. > >> > > > >> > > The real issue of my problem is that the FIRST patch Dave Airlie > >> > > attached for resolving this Compiz issue NEVER reached kernel mainline > >> > > while the second one did obviously. > >> > > > >> > > So PLEASE do push up Dave's FIRST patch titled "fallback on VRAM memory > >> > > placement" as fast as possible so that it becomes part of the kernel > >> > > mainline! > >> > > >> > The first patch caused problems on some AGP systems due to the > >> > unreliability of AGP so it wasn't pushed to mainline. It should be > >> > safe to push once this patch hits mainline: > >> > http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=61cf059325a30995a78c5001db2ed2a8ab1d4c36 > > > > No, there were more issues with the patch[0] and it can't be pushed > > again as is. A different approach will be needed to make things work > > better on VRAM-limited systems. > > > > > > [0] At least making pinning of BOs to VRAM unreliable, potentially > > causing problems with BOs used by the display hardware (e.g. trying to > > start a second X server when VRAM is full of BOs), and degrading > > performance on systems where things work without the patch. > > Yeah I'm going to try and fix that up this week now we fixed the AGP. > > I'm just going to separate the pinning code from the validate code wrt > domain->placement translation. That's a start, but IME validation using the new scheme degrades performance on setups which work with the old scheme. Maybe the old scheme can be tried first and the new one as a fallback, at least as an interim solution. But I think the new scheme really shouldn't be necessary if we didn't over-report the amount of VRAM available to userspace and prevented fragmentation due to pinned BOs, which should be feasible. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: ATI Radeon R100 QD (7200) refuses to work with Compiz (Kernel 2.6.34-rc4)
On Son, 2010-04-25 at 11:35 +0200, Uwe Bugla wrote: > Am Samstag, den 24.04.2010, 12:31 -0400 schrieb Alex Deucher: > > On Sat, Apr 24, 2010 at 11:48 AM, Chicken Shack > > wrote: > > > Am Donnerstag, den 22.04.2010, 01:36 -0400 schrieb Alex Deucher: > > >> On Mon, Apr 19, 2010 at 4:25 AM, Uwe Bugla wrote: > > >> > Hi, > > >> > I am running kernel 2.6.33-rc4 on a Debian Testing Squeeze release. > > >> > I have debianized the latest driver snapshot from > > >> > http://cgit.freedesktop.org/xorg/driver/xf86-video-ati. > > >> > > > >> > So I am using the ATI driver version 6.13 in connection with the latest > > >> > Radeon driver in kernel with KMS enabled. > > >> > Everything is fine so far, until I try to start Compiz: > > >> > > > >> > "drmRadeonCmdBuffer: -12. Kernel failed to parse or rejected command > > >> > stream. See dmesg for more info." > > >> > > >> What does dmesg say? This looks like a dupe of bug 26302: > > >> https://bugs.freedesktop.org/show_bug.cgi?id=26302 > > >> > > >> Alex > > >> > > >> > > > >> > This is the message when Compiz is started via "compiz --replace &" > > >> > > > >> > The card's memory is 32 MB Video RAM - it's a quite old one :)) > > >> > > > >> > I do NOT use a specified xorg.conf in connection with > > >> > xserver-xorg-1.7.6, as it is a new driver where everything is being > > >> > managed via KMS. > > >> > > > >> > And that's it what Gnome's System Information spurks out under Computer > > >> > -> Display: > > >> > > > >> > Vendor Tungsten Graphics, Inc. > > >> > RendererMesa DRI R100 (R100 5144) 20090101 x86/MMX/SSE2 TCL > > >> > DRI2 > > >> > Version 1.3 Mesa 7.9-devel > > >> > Direct Rendering Yes > > >> > > > >> > So everything is OK except the "-12" kernel crash above, performed > > >> > every > > >> > time when I try to start Compiz Fusion. > > >> > > > >> > Any idea or patches available? > > >> > > > >> > Thanks! > > >> > > > >> > If you need further information please ask me for it. > > >> > > > >> > Uwe > > >> > > > >> > P. S.: I compile the Mesa Library as described in the Internet, but > > >> > with > > >> > two exceptions: > > >> > > > >> > a. I do not take the master branch, I prefer Luca Barbieri's > > >> > nvfx-next-branch instead because I need > > >> > a working solution for my two Nvidia NV34 cards, and Compiz works if I > > >> > use that branch while the master > > >> > repo is not yet compatible with Compiz. > > >> > > > >> > b. I do not take "disable-gallium" as a configure switch, I prefer > > >> > "-enable gallium-nouveau" instead because > > >> > I do need a functionable Gallium nouveau driver too when compiling the > > >> > mesa library. > > >> > > > >> > c. When will Luca Barbieri's nvfs-next-tree be synchronized with the > > >> > master tree? > > >> > > > >> > d. Is it possible that the current ATI driver's texture size is erratic > > >> > (i. e. too big)? I have no idea where the error could result from! > > >> > > > >> > e. Although stated differently in the error message above neither the > > >> > dmesg nor the xorg.0.log file reveal any information that could be > > >> > really helpful. > > >> > > > >> > > > >> > > > > > > > Hi Alex, > > > > > > 1. The real issue of that Compiz problem IS NOT what dmesg says. > > > > > > The real issue of my problem is that the FIRST patch Dave Airlie > > > attached for resolving this Compiz issue NEVER reached kernel mainline > > > while the second one did obviously. > > > > > > So PLEASE do push up Dave's FIRST patch titled "fallback on VRAM memory > > > placement" as fast as possible so that it becomes part of the kernel > > > mainline! > > > > The first patch caused problems on some AGP systems due to the > > unreliability of AGP so it wasn't pushed to mainline. It should be > > safe to push once this patch hits mainline: > > http://git.kernel.org/?p=linux/kernel/git/airlied/drm-2.6.git;a=commit;h=61cf059325a30995a78c5001db2ed2a8ab1d4c36 No, there were more issues with the patch[0] and it can't be pushed again as is. A different approach will be needed to make things work better on VRAM-limited systems. [0] At least making pinning of BOs to VRAM unreliable, potentially causing problems with BOs used by the display hardware (e.g. trying to start a second X server when VRAM is full of BOs), and degrading performance on systems where things work without the patch. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Fwd: mapping of minimized windows
On Fre, 2010-04-23 at 11:41 +0200, Florian Martys wrote: > -- Forwarded message -- > From: Florian Martys > Date: 2010/4/23 > Subject: Re: mapping of minimized windows > To: Michel Dänzer > > > Thank you for your answer, Michel! > Although not being a developer, from what I read so far everything > points towards X being the upstream part responsible for this issue... No, 'minimized windows' is entirely a window manager concept. > Leaving the Scale Plugin aside, the ALT-TAB behaviour can't be a > Compiz issue, right? As far as I understand you, you don't want map > minimized windows yourself (in X) because of higher ressources needed? > Well, don't you agree at all it is a usability bug and there has to be > done something about it? Any ideas how to minimize the ressources > needed? For instance by not constantly refreshing minimized windows > like you do it with active windows, couldn't you save a lot of > ressources by just saving a "screenshot" (probably what you meant with > the last pixmap anyway)? Exactly. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: mapping of minimized windows
On Fre, 2010-04-23 at 11:22 +0200, Florian Martys wrote: > > Why I am here: > I'm new to the mailing list, so please excuse potential naivety. I > filed a bugreport against xorg package in Ubuntu on Launchpad* and > have been told that the problem is upstream and I have to ask the xorg > team in their mailing list, here I am. > > What I am here for: > I am using standard Ubuntu desktop (10.04) with Desktop effects > (Compiz Fusion). First, when using ALT-TAB to switch between windows I > can only see an icons instead of window previews when toggling over > minimized windows (bugreport**). Second, when using the Scale > plugin*** (WIN-key aka SUPER+A or W; extra desktop effects have to be > enabled), which is similar to the Exposé effect on Mac OS X, I can > only see windows that are avitve (i.e. not minimized), there is not > even an icon replacing the missing running application that are > minimized, minimized applications/windows don't even show up. > > As I understand this is not a bug, but more or less by design, because > minimized windows are not mapped anymore. However it is a usability > bug when using ALT-TAB or the Scale Plugin with the Desktop Effects. It's up to compiz. It could (optionally) either not unmap minimized windows or just keep the last pixmap for them. I think it would have to be optional because in both cases minimized windows would use up more resources than before. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Ati Radeon driver xf86-video-ati (6.13) causes segfaults xorg-xserver 1.8.0
On Mit, 2010-04-14 at 19:23 +0200, Michel Dänzer wrote: > On Wed, 2010-04-14 at 16:48 +0200, cour...@web.de wrote: > > > > from time to time when using firefox my xserver crashing > > > > Meanwhile i could trace this bug > > Might be https://bugs.freedesktop.org/attachment.cgi?id=34759 . Whoops, I meant https://bugs.freedesktop.org/show_bug.cgi?id=27510 , the fix for which is now in xserver Git master and server-1.8-branch. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Ati Radeon driver xf86-video-ati (6.13) causes segfaults xorg-xserver 1.8.0
On Wed, 2010-04-14 at 16:48 +0200, cour...@web.de wrote: > > from time to time when using firefox my xserver crashing > > Meanwhile i could trace this bug Might be https://bugs.freedesktop.org/attachment.cgi?id=34759 . -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: please fix link on website
On Thu, 2010-04-08 at 11:57 +0200, melodra...@online.de wrote: > hello > > on the website, the direct link to write an email to the xorg mailing > list under: > > Reporting problems, asking questions and getting help > > opens a composer window without further arguments (body=subscribe...). > however, sent emails get rejected without earlier subscription. please > fix this link or the behaviour of the mailing list. Preferably the latter: there are volunteers processing the xorg list moderation queue, so there's no point being rude by automatically rejecting non-subscriber posts. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xserver 1.8.0 radeonhd crashing
On Tue, 2010-04-06 at 10:30 +0200, Artur Skawina wrote: > Upgraded xorg to git head a few days ago, today tried to view a youtube page > in ff3.6 and every attempt leads to an xserver segfault at 0x10. > Server backtrace (below) didn't contain much info; gdb version looks like > this: > > #0 0xf770b430 in __kernel_vsyscall () > #1 0xf7456a55 in *__GI_raise (sig=6) > at ../nptl/sysdeps/unix/sysv/linux/raise.c:64 > #2 0xf7457fe4 in *__GI_abort () at abort.c:88 > #3 0x080a6de4 in OsAbort () at ../../os/utils.c:1321 > #4 0x080be93e in ddxGiveUp () at > ../../../../hw/xfree86/common/xf86Init.c:1238 > #5 0x080be9c1 in AbortDDX () at ../../../../hw/xfree86/common/xf86Init.c:1284 > #6 0x080b5d2d in AbortServer () at ../../os/log.c:418 > #7 0x080b6495 in FatalError ( > f=0x81cf2f4 "Caught signal %d (%s). Server aborting\n") > at ../../os/log.c:546 > #8 0x080ac011 in OsSigHandler (signo=11, sip=0xffa63a8c, unused=0xffa63b0c) > at ../../os/osinit.c:156 > #9 > #10 0xf72cfefb in R300CheckComposite (op=3, pSrcPicture=0x88a63f0, > pMaskPicture=0x88a6460, pDstPicture=0x86ec9c8) > at ../../src/radeon_exa_render.c:1228 > #11 0xf723227c in exaTryDriverComposite (op=0 '\000', pSrc=0x88a63f0, > pMask=0x88a6460, pDst=0x86ec9c8, xSrc=275, ySrc=334, xMask=0, yMask=0, > xDst=275, yDst=334, width=77, height=23) at ../../exa/exa_render.c:695 > #12 0xf7233590 in exaComposite (op=3 '\003', pSrc=0x88a63f0, pMask=0x88a6460, > pDst=0x86ec9c8, xSrc=275, ySrc=334, xMask=0, yMask=0, xDst=275, yDst=334, > width=77, height=23) at ../../exa/exa_render.c:1034 Most likely pSrcPicture->pDrawable is NULL (i.e. it's a source-only, solid or gradient picture) in R300CheckComposite(), and that fails to check the pointer before dereferencing it. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Broken brightness/gamma in SDL
On Thu, 2010-03-25 at 14:10 +0100, Sven Arvidsson wrote: > > Apparently Xorg 7.5 broke the brightness/gamma function[1] used in SDL, > leaving a lot of games too dark or too bright. > > Can somebody who's familiar with this give the SDL devs a hand? > http://bugzilla.libsdl.org/show_bug.cgi?id=971 > > 1. http://lists.freedesktop.org/archives/xorg/2009-February/043953.html Assuming 'Xorg 7.5' means xserver 1.6.x, I think this should be fixed in the current xserver 1.7.x releases. For SDL, the best solution would be to set the gamma ramp via the RandR extension when possible. Otherwise IIRC it needs to watch for a VidMode extension gamma ramp size of 0 and use XF86VidModeSetGamma() in that case. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xserver doesn't support XvPutImage to Pixmap?
On Wed, 2010-02-17 at 08:13 +0200, Matthew Fincham wrote:
> On 17-02-10 07:57, Matthew Fincham wrote:
> > On 16-02-10 17:27, Michel Dänzer wrote:
> >
> >> On Tue, 2010-02-16 at 14:17 +0200, Matthew Fincham wrote:
> >>
> >>
> >>> On 16-02-10 11:29, Michel Dänzer wrote:
> >>>
> >>>
> >>>> On Tue, 2010-02-16 at 10:39 +0200, Matthew Fincham wrote:
> >>>>
> >>>>
> >>>>
> >>>>> Currently I am using XvPutImage to display a video stream. The video
> >>>>> needs to be overlayed with various items (pixmaps, text, custom
> >>>>> drawing). As it stands there is a lot of flickering of the overlayed
> >>>>> items. When this is double-buffered (using standard pixmaps) the
> >>>>> flickering, obviously, goes away.
> >>>>>
> >>>>> I see that XVPutImage does not support writing to pixmaps, only to
> >>>>> windows (xf86XVEnlistPortInWindow seems to be the start of the
> >>>>> problem...). The system is running version 1.3.0. I have checked 1.7.1
> >>>>> and seen that it too doesn't support XVPutImage to pixmaps.
> >>>>>
> >>>>> I have a few questions:
> >>>>>
> >>>>> - has any progress been made in supporting XVPutImage with pixmaps?
> >>>>>
> >>>>>
> >>>>>
> >>>> Somewhat:
> >>>>
> >>>> http://bugs.freedesktop.org/show_bug.cgi?id=2114
> >>>>
> >>>>
> >>> Hi Michel
> >>>
> >>> Thanks for the link. I have applied the patch (from Kusanagi Kouichi)
> >>> but only managed to crash the X server when writing to a pixmap. I
> >>> recompiled Xorg, the (Intel) drivers and the app using drawing the Xv
> >>> image.
> >>>
> >>> Afetr applying the patch should I expect to be able to write to pixmaps,
> >>> or have I done something wrong (left out a recompile or something else)!
> >>>
> >>>
> >> As I mentioned in http://bugs.freedesktop.org/show_bug.cgi?id=21143#c7
> >> the patch as it stands breaks the video driver ABI, so the video driver
> >> needs to be rebuilt against the patched xserver. If that wasn't the
> >> problem, please provide a backtrace of the crash.
> >>
> >>
> >>
> >>
> > This is the backtrace, although I am not 100% confident of it. Certainly
> > the references to qt4 are wrong. I'll see if I can get more info.
> >
> > Core was generated by `Xorg'.
> > Program terminated with signal 6, Aborted.
> > #0 0xbba1a22f in kill () from /usr/pkg/qt4/lib/libc.so.12
> > (gdb) bt
> > #0 0xbba1a22f in kill () from /usr/pkg/qt4/lib/libc.so.12
> > #1 0xbbab6340 in abort () from /usr/pkg/qt4/lib/libc.so.12
> > #2 0x0809ad6e in ddxGiveUp ()
> > #3 0x0819a3b7 in AbortServer ()
> > #4 0x0819a83f in FatalError ()
> > #5 0x080b6d0c in xf86SigHandler ()
> > #6
> > #7 0x001f in ?? ()
> >
> > Many thanks
> > Matthew
> >
> >
> >
> From line 1749 in hw/xfree86/common/xf86xv.c (the xf86XVPutImage function):
>
>/* If we are changing windows, unregister our port in the old window */
> if(portPriv->pDraw&& (portPriv->pDraw != pDraw))
> xf86XVRemovePortFromWindow((WindowPtr)(portPriv->pDraw), portPriv);
>
>/* Register our port with the new window */
>ret = xf86XVEnlistPortInWindow((WindowPtr)pDraw, portPriv);
>if(ret != Success) goto PUT_IMAGE_BAILOUT;
>
>if(!REGION_NOTEMPTY(pScreen,&ClipRegion)) {
> clippedAway = TRUE;
> goto PUT_IMAGE_BAILOUT;
>}
>
>
> If a return is done before xf86XVEnlistPortInWindow X does not crash. If
> a return is done after xf86XVEnlistPortInWindow X crashes. Rather crude
> debugging, I know. Now I don't know the X code at all, but I see that
> the xf86XVEnlistPortInWindow casts the drawable to a WindowPtr. I
> presume this will cause problems if the drawable is in fact a pixmap...
Right, that code only makes sense if the drawable actually is a window.
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xserver doesn't support XvPutImage to Pixmap?
On Tue, 2010-02-16 at 14:17 +0200, Matthew Fincham wrote: > On 16-02-10 11:29, Michel Dänzer wrote: > > On Tue, 2010-02-16 at 10:39 +0200, Matthew Fincham wrote: > > > >> Currently I am using XvPutImage to display a video stream. The video > >> needs to be overlayed with various items (pixmaps, text, custom > >> drawing). As it stands there is a lot of flickering of the overlayed > >> items. When this is double-buffered (using standard pixmaps) the > >> flickering, obviously, goes away. > >> > >> I see that XVPutImage does not support writing to pixmaps, only to > >> windows (xf86XVEnlistPortInWindow seems to be the start of the > >> problem...). The system is running version 1.3.0. I have checked 1.7.1 > >> and seen that it too doesn't support XVPutImage to pixmaps. > >> > >> I have a few questions: > >> > >> - has any progress been made in supporting XVPutImage with pixmaps? > >> > > Somewhat: > > > > http://bugs.freedesktop.org/show_bug.cgi?id=2114 > Hi Michel > > Thanks for the link. I have applied the patch (from Kusanagi Kouichi) > but only managed to crash the X server when writing to a pixmap. I > recompiled Xorg, the (Intel) drivers and the app using drawing the Xv image. > > Afetr applying the patch should I expect to be able to write to pixmaps, > or have I done something wrong (left out a recompile or something else)! As I mentioned in http://bugs.freedesktop.org/show_bug.cgi?id=21143#c7 the patch as it stands breaks the video driver ABI, so the video driver needs to be rebuilt against the patched xserver. If that wasn't the problem, please provide a backtrace of the crash. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xserver doesn't support XvPutImage to Pixmap?
On Tue, 2010-02-16 at 10:39 +0200, Matthew Fincham wrote: > > Currently I am using XvPutImage to display a video stream. The video > needs to be overlayed with various items (pixmaps, text, custom > drawing). As it stands there is a lot of flickering of the overlayed > items. When this is double-buffered (using standard pixmaps) the > flickering, obviously, goes away. > > I see that XVPutImage does not support writing to pixmaps, only to > windows (xf86XVEnlistPortInWindow seems to be the start of the > problem...). The system is running version 1.3.0. I have checked 1.7.1 > and seen that it too doesn't support XVPutImage to pixmaps. > > I have a few questions: > > - has any progress been made in supporting XVPutImage with pixmaps? Somewhat: http://bugs.freedesktop.org/show_bug.cgi?id=21143 -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Slow 2D with radeon KMS
On Mon, 2010-02-15 at 16:34 +0100, Damien Mir wrote: > > vsync was broken when intel merged the new vsync code. So you should > > use mesa from time before the merge (about a week ago) > > > > Unfortunately I cannot get vsync working anyhow with Kwin compositing (KDE > 4.3). > > Any combination of xserver (1.6 / 1.7 / 1.7.99) / Mesa (7.7 or git) gives > the same results on an R700 HD4650 mobility. > > Any idea on what's going on ? Sorry if it's a bit OT, but does it seem > related to the R700/xorg/mesa mix ? or might it be something completely > different ? > Because being unable to play tear-free videos quite kills a nice > compositing experience ! > Note : Xv playback is tear-free with kwin compositing disabled This should be fixed with current xf86-video-ati Git, at least for OpenGL compositing. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Remote X
On Tue, 2010-02-02 at 23:33 -0800, Corbin Simpson wrote: > In theory, sure, but I don't think I've ever seen anybody actually > have any problems with this. In my experience the glyph cache is > actually too big sometimes; when doing 3D drivers, if I accidentally > clobber my cache, I need to go open up a character map and scroll > through a dozen fonts to clear it. That's the EXA glyph cache pixmap, whereas Russell was presumably referring to the generic RENDER mechanism of the X server caching glyph data uploaded by the clients (which is currently done by storing each cached glyph in a pixmap of its own). I agree with others though that his concern seems rather hypothetical. > On Tue, Feb 2, 2010 at 6:18 AM, Russell Shaw wrote: > > Hi, > > Is remote execution of X clients away from the X server still regarded > > as a design goal, or does everyone just develop for client applications > > that only run on or close to the X server machine? > > > > With a unicode text widget, every time a character is entered, the > > line or paragraph(s) need to be moved and/or reshaped. This can mean > > sending a few largish bitmaps for every key press. Other toolkits > > may add new polygon tesselated glyphs to the XRender cache: > > > > http://www.keithp.com/~keithp/talks/usenix2001/ > > http://cgit.freedesktop.org/xorg/proto/renderproto/plain/renderproto.txt > > > > With a cursive font, all the cursive glyphs on a line could compress > > when the line is close to full, but before the need for a linebreak. > > That would stress out the cache advantage of XRender. Another problem > > with XRender is that it's computationally expensive for small systems > > without polygon hardware. > > _______ > > xorg mailing list > > xorg@lists.freedesktop.org > > http://lists.freedesktop.org/mailman/listinfo/xorg > > > > > -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: exaGetPixmapFirstPixel Question
On Tue, 2010-01-19 at 13:42 +0900, Soo Chan Lim wrote:
> Hi.
> I am trying to make a ddx exa video driver at my owned target.
> When I test the driver, I have met some error from Xserver.
> The error log is bleow,
> =
> Fatal server error:
> exaGetPixmapFirstPixel called for invalid bpp 1
> =
>
> And backtrace at the exaGetPixmapFirstPixel function is below
> ==
>
> Breakpoint 1, exaGetPixmapFirstPixel (pPixmap=0x477618)
> at ../../exa/exa_unaccel.c:507
> 507 switch (pPixmap->drawable.bitsPerPixel) {
> (gdb) bt
> #0 exaGetPixmapFirstPixel (pPixmap=0x477618)
> at ../../exa/exa_unaccel.c:507
> #1 0x406529c0 in exaTryDriverSolidFill (pSrc=0x488ec0,
> pDst=0x488ce0,
> xSrc=0, ySrc=0, xDst=5, yDst=10, width=1, height=127)
> at ../../exa/exa_render.c:300
> #2 0x40654c88 in exaComposite (op=1 '\001', pSrc=0x488ec0,
> pMask=0x0,
> pDst=0x488ce0, xSrc=0, ySrc=0, xMask=0, yMask=0, xDst=5, yDst=10,
> width=1, height=127) at ../../exa/exa_render.c:923
> #3 0x0014ccc4 in damageComposite (op=1 '\001', pSrc=0x488ec0,
> pMask=0x0,
> pDst=0x488ce0, xSrc=0, ySrc=0, xMask=0, yMask=0, xDst=5, yDst=10,
> width=1, height=127) at ../../../miext/damage/damage.c:643
> #4 0x0013392c in CompositePicture (op=1 '\001', pSrc=0x488ec0,
> pMask=0x0,
> pDst=0x488ce0, xSrc=0, ySrc=0, xMask=0, yMask=0, xDst=5, yDst=10,
> width=1, height=127) at ../../render/picture.c:1718
> #5 0x0013b24c in ProcRenderComposite (client=0x433898)
> at ../../render/render.c:723
> #6 0x00140324 in ProcRenderDispatch (client=0x433898)
> at ../../render/render.c:2056
> #7 0x00024650 in Dispatch () at ../../dix/dispatch.c:445
> #8 0x00022414 in main (argc=11, argv=0xbec9bd04, envp=0xbec9bd34)
> at ../../dix/main.c:285
> (gdb) p pPixmap->drawable.bitsPerPixel
> $1 = 1 '\001'
> =
>
> At exaGetPixmapFirstPixel, the xserver calls the FatalError when the
> bpp of the pixmap is 1.
>
> I have two questions at this point.
> 1. Is this exa module bug? I mean the xserver has the bug?
Yeah, exaGetPixmapFirstPixel() and/or its caller probably needs to be
fixed to handle this.
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xorg crashes...
On Thu, 2010-01-07 at 11:47 +1000, Peter Hutterer wrote: > On Wed, Jan 06, 2010 at 08:26:40PM -0500, Ryan Daly wrote: > > On 01/06/2010 08:04 PM, Peter Hutterer wrote: > > >> The backtrace is pretty consistent with the following few lines: > > >> > > >> Program received signal SIGTERM, Terminated. > > >> 0x7f146bab8110 in __close_nocancel () from /lib/libpthread.so.0 > > >> (gdb) backtrace r full > > >> #0 0x7f146bab8110 in __close_nocancel () from /lib/libpthread.so.0 > > >> No symbol table info available. > > >> #1 0x7f1466f61516 in ?? () from > > >> /usr/lib/xorg/modules/input//evdev_drv.so > > >> No symbol table info available. > > >> #2 0x00447723 in DisableDevice (dev=0x18a33a0) at > > >> ../../dix/devices.c:407 > > >> > > >> Are those lines pointing to a device or to the card possibly? > > >> > > >> I'm running the same version of Ubuntu on three different machines, and > > >> I'm only experiencing the Xorg restarts on one system. I'm at a loss... > > > > > > > > > uhm. SIGTERM is the termination signal. Something's shutting down your > > > server. > > > > Right, but it's nothing I'm doing. That's the problem. I'm not > > initiating an exit, nor am I hitting ctrl-backspace (I don't think > > that's enabled by default any longer anyway). > > > > I'm looking for suggestions as to WHAT may be causing the SIGTERM. > > either your session is terminating for some reason or another or you might > be getting an unresolved symbol error. that terminates the server as well. > try starting the server from a TTY instead of through gdm, once it exits you > can see if it complains about a symbol error. That would be SIGKILL though, or some other signal that can't be caught. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Is xorg-server-1.7.3 necessary to modify to suit FreeBSD?
On Wed, 2009-12-23 at 11:56 +0800, Sagara Wijetunga wrote: > > In Tomahawk Desktop 2.0 Beta1 we got an issue, that when try to run the > KDE, the X server crashes. Do you have a backtrace (preferably from gdb) of the crash? -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
RE: Update from X11R6.7 to X11R7.5
On Fri, 2009-11-20 at 15:02 +, Maria del Rosario Lopez-Gonza wrote: > > (EE)VMWARE(0):“Currently unavailable depth/bpp of 16/16 requested. The > guess X server must run at the same depth and bpp as the host (which > is currently 24/32). This is automatically detected” Pl do not specify > a depth on the command line or via the config file” Have you tried following this advice? -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: i915: FBO performance
On Fri, 2009-10-02 at 21:42 +0200, Thomas Zimmermann wrote:
> Hi there,
>
> lately I've been playing around with OpenGL framebuffer objects while
> trying out shadow mapping with GL. The FBO is thereby used to render
> depth values to a texture, which is later needed for shadowing.
>
> When I attach renderbuffer objects or texture objects that have ~1000
> pixel per dimension to the framebuffer object, the framerate is ~160
> fps. However, in the range between 1009 to 1024 pixels per dimension,
> the performance drops to ~35 fps. For higher numbers of pixels (>=1025)
> the performance again goes up to ~160 fps.
>
> I've searched bugzilla and the ML archive for this, but haven't found
> anything. Also, the changelogs of the intel driver releases 2.8 and 2.9
> do not seem to contain any related entries.
>
> I'm on a system with a Core2 Duo x64-64, and an Intel 945 graphics chip.
> My distribution is an up-to-date Fedora 11, with Intel's xorg graphics
> driver 2.7.
See Mesa Git commit bcdaed2c0a4e70c3dd7c4648442c97540f3c9f1f:
/* XXX: At least the i915 seems very upset when the pitch is a multiple
* of 1024 and sometimes 512 bytes - performance can drop by several
* times. Go to the next multiple of 64 for now.
*/
if (!(mt->pitch & 511))
mt->pitch += 64;
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [exa] problem with openchrome driver?
On Sat, 2009-09-26 at 12:58 +0200, Tomek wrote: > Hello. First of all I type what I am using: > -openchrome driver rev. 794 > -xorg-server and libraries,protos form git (from today) > -mesa and libgl also from git (today) > > My xorg.0.log, xorg.conf and screenshot is in the attachment. > > I use kde from svn (4.3.69) and have disabled desktop effects.When I use > XAA accel method all is fine,but when I switch to EXA - then I have got > some problems with windows in kde. No matter what theme I use, always is > the same strange error in rendering window (as you see on picture). In > other hand when I enable desktop effects (XRender, bacause opengl is too > slow in openchrome) in exa mode then this problem dont exist. Did the problem start after updating a certain component, e.g. xserver? > X.Org X Server 1.6.99.901 (1.7.0 RC 1) If you're really using xserver from Git, it seems not quite up to date. Which commit is it exactly? > (**) CHROME(0): Option "MigrationHeuristic" "greedy" Does the problem happen without this option? -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Xserver crashes with ATI RADEON MOBILITY M9.
On Thu, 2009-09-24 at 10:55 +0530, suganthan wrote: > Sir, >Thanks for your valid input. > Now i got the values of Video Bios,What i tried is ? > > I put the card in a an Intel based desktop, > Hacked the bios location & loaded its values to a file, hardcoded the > values in the radeon_driver.c file. > > Now when in run the X it passes that location & the Xserver crashes. > > PFA with attached the Xorg.0.log file. The log file seems truncated. If 'X server crashes' means the process dies, this could be due to an unresolved symbol. Check the X server stderr output. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Different color depths per head by default?
On Mon, 2009-09-14 at 03:22 +0200, Csillag Kristof wrote: > > I have encountered another weird thing when setting up my displays. > > On X startup, the gradient background image of the login > screen fills up both screens (as it should). > On the right monitor (connected to DVI-0), the gradient is continuous, > but on the left one (connected to DVI-1), large stripes are visible. > > Previously, I seen such stripes when I was using 16bpp > (instead of 24 or 32bpp), [...] The root weave consists only of black and white pixels, which can be represented perfectly at any colour depth. So 'stripes' doesn't sound like something that could be caused by a different depth. It rather sounds like either the pattern isn't rendered correctly to the framebuffer or that the framebuffer contents aren't displayed properly, e.g. due to imperfect synchronization of a digital display to an analog signal. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: problem getting pseudocolor
On Wed, 2009-09-02 at 09:41 +0100, David Gerard wrote: > 2009/9/2 Jerome Glisse : > > > We don't test/use pseudocolor much, i don't even know if it's supposed > > to work. Why do you want pseudocolor ? You should really stick with > > RGB32bits visual. > > > I would guess: shitty, shitty vertical-market proprietary software > that thinks it's 1990 and DEMANDS 8-bit colour, and won't run in > 24-bit colour. I've encountered this stuff. Awful, awful. And > occasionally necessary. Those who need that should consider working on http://bugs.freedesktop.org/show_bug.cgi?id=4770 -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Something is strange since xorg-server 1.6.1
On Wed, 2009-08-26 at 11:20 -0700, Simonas Snarskas wrote: > 2009/8/26, Simonas Snarskas : > > Good evening, > > I have had a problem with xorg-server 1.5, when i browsed web and > > flash the scrolling becames very laggy. For example, open youtube > > clip, and scroll down with mousewheel, i will see big lag with > > scrolling. No matter what flash version or browser im using, the > > problem persisted. But, when i upgraded to xorg-server 1.6.0 that > > problem gone! I was so happy and thankful to you. Now, when i upgraded > > to 1.6.1 i started to see this problem again. It looks like that > > problem is back from xorg-server 1.5. Hmm, that's with stock 1.6.0 and 1.6.1, no distribution patches? If so, that's weird on the one hand, as I don't see any obviously relevant changes between them. But on the other hand this should make it rather easy to isolate the offending change in Git. > > Also i experienced new problem, when i try to switch from compiz to > > metacity or vice versa my xserver crashes and i go back to login > > screen. 1.6.2 and 1.6.3 didnt fix these issues. This should be fixed in 1.6.3.901. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: can't start with xorg-video-fbdev/vt8623fb
On Thu, 2009-08-06 at 10:38 -0400, Alejandro Mery wrote: > > On 06/08/09 03:58, Michel Dänzer wrote: > > On Mit, 2009-08-05 at 20:16 -0400, Alejandro Mery wrote: > >> Hello, > >> > >> I need to run an X server in a tiny x86 machine. I wanted to do so > >> using fb but whatever I do ends up with: > >> > >> (EE) FBDEV(0): FBIOPUT_VSCREENINFO succeeded but modified mode > >> > >> linux26 2.6.27.29 (vt8623fb) > >> xorg-server 1.5.3 > >> xf86-video-fbdev 0.4.0 (and later 0.4.1) > > > > There's a fix in xserver 1.6.x to avoid a false positive of the check > > above due to pixel clock rounding errors. If that doesn't help, there > > may be a bug in vt8623fb. > > > > is that fix the one from > <https://bugzillafiles.novell.org/attachment.cgi?id=161573> or there > is more? I mean http://cgit.freedesktop.org/xorg/xserver/commit/?id=bf333c2f9833a178887e7bdd7fc338f1e09c387f > I'm about to try kdrive and xorg-video-openchrome as alternatives A specific driver for your hardware should be better than a generic driver like fbdev anyway. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: can't start with xorg-video-fbdev/vt8623fb
On Mit, 2009-08-05 at 20:16 -0400, Alejandro Mery wrote: > Hello, > > I need to run an X server in a tiny x86 machine. I wanted to do so > using fb but whatever I do ends up with: > > (EE) FBDEV(0): FBIOPUT_VSCREENINFO succeeded but modified mode > > linux26 2.6.27.29 (vt8623fb) > xorg-server 1.5.3 > xf86-video-fbdev 0.4.0 (and later 0.4.1) There's a fix in xserver 1.6.x to avoid a false positive of the check above due to pixel clock rounding errors. If that doesn't help, there may be a bug in vt8623fb. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Overlay colorkey always painted to root window
On Don, 2009-08-06 at 15:02 +0800, Yuan, Shengquan wrote: > > In current Xorg graphics drivers, including SIS, intel, ATI, MGA, > overlay color key is always painted to root window. The driver may > call Xserver helper function xf86XVFillKeyHelper, [...] Stop right there. :) Since xserver 1.3, there's a new xf86XVFillKeyHelperDrawable helper which draws to the actual drawable. This is used by the radeon driver and it works as nicely as one can expect an overlay to work with compositing. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Radeon ( RV280 ) DRI2 status
On Fri, 2009-07-31 at 14:50 +1000, Dan wrote: > > I have managed to get a KMS kernel booting without oopsing. > radeon.agpmode=-1 does the trick. I have 2 problems now. Firstly, the > mode that KMS brings up is out of sync for my LCD monitor. Does the > driver detect the capabilities of the attached monitor, or does it use > hard-coded defaults? > > Anyway, when X starts ( xf86-video-ati & mesa from git ), things come > to life again. X reports that DRI2 has initialised. My next problem is > that ecomorph & compiz run very, very slowly. The screen will redraw a > small section, near where the mouse is, every 5 seconds or so. Is this > to be expected? Or should I get usable performance in compiz? First of all, PCI GART is known to be much slower than AGP. You should really try to figure out what's wrong with AGP. Maybe you can post dmesg output showing the failure to the xorg-driver-ati list. Also, until we've ironed out some inefficiencies with compiz direct rendering, it may actually perform better with indirect rendering. YMMV. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: virtual screen > 2048 pixels, Intel 945
On Wed, 2009-07-29 at 09:31 +0100, Colin Guthrie wrote: > 'Twas brillig, and McDonald, Michael-p7438c at 28/07/09 21:31 did gyre > and gimble: > > Hmm, the abstract for the Linux Plumbers Conference paper to be > > presented in September claims Shatter is an EXA extension and > > IntelLinuxGraphics 2.8 dropped EXA support. Doesn't sound like it'll > > help the 945 guys after all! :-) > > Nah, have faith, it will :) > > Shatter started off as EXA but it will move to UXA (UXA is basically > very similar to EXA but with a different memory manager and some other > gubbins I don't fully appreciate!). Sure about that? Comparatively simple EXA improvements (e.g. eliminating software fallbacks from exaGlyphs when there's no mask) have yet to be ported to UXA after almost half a year. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: EXA bug: Calling FinishAccess on pixmap 0xaf06d008 with index 1 while it should have been (nil).
On Tue, 2009-07-21 at 12:14 +0200, Maarten Maathuis wrote:
> > +/* If slot for this index is taken, find an empty slot */
> > +if (pExaScr->access[index].pixmap) {
> > + for (index = EXA_NUM_PREPARE_INDICES - 1; index >= 0; index--)
> > + if (!pExaScr->access[index].pixmap)
> >break;
> > +}
>
> Maybe add a note in the headerfile that people cannot assume that the
> word src or dst has any meaning with regards to usage (wrt to specific
> optimisations).
Done and pushed.
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: EXA bug: Calling FinishAccess on pixmap 0xaf06d008 with index 1 while it should have been (nil).
[ Please quote what you're referring to ]
On Sun, 2009-07-19 at 12:25 +0200, Maarten Maathuis wrote:
> That would suggest creating a GC that completely bypasses exa.
I'm not sure that would really be a problem, but anyway it turns out
this doesn't work because GetScratchGC() may return a pre-allocated GC.
> The proper solution seems like adding more indices or at least
> detecting that the indices are being used.
The patch below fixes the problem by reference counting
Prepare/FinishAccess.
commit 27786a280eb7c6b852e376affb6daf4d9cca4b9e
Author: Michel Dänzer
Date: Mon Jul 20 11:57:38 2009 +0200
EXA: Make Prepare/FinishAccess tracking resilient to repeated / nested
calls.
Use reference counting and do nothing unless the reference count transitions
to/from 0.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=22822 .
As a bonus, this avoids calling the driver Prepare/FinishAccess hooks more
than
once per pixmap and operation.
diff --git a/exa/exa.c b/exa/exa.c
index 8d488b3..daa4a7a 100644
--- a/exa/exa.c
+++ b/exa/exa.c
@@ -554,6 +554,7 @@ ExaDoPrepareAccess(DrawablePtr pDrawable, int index)
PixmapPtr pPixmap = exaGetDrawablePixmap (pDrawable);
ExaPixmapPriv(pPixmap);
Bool offscreen;
+int i;
if (!(pExaScr->info->flags & EXA_OFFSCREEN_PIXMAPS))
return FALSE;
@@ -561,19 +562,25 @@ ExaDoPrepareAccess(DrawablePtr pDrawable, int index)
if (pExaPixmap == NULL)
EXA_FatalErrorDebugWithRet(("EXA bug: ExaDoPrepareAccess was called on
a non-exa pixmap.\n"), FALSE);
-/* Check if we're dealing SRC == DST or similar.
- * In that case the first PrepareAccess has already set
pPixmap->devPrivate.ptr.
- */
-if (pPixmap->devPrivate.ptr != NULL) {
- int i;
- for (i = 0; i < 6; i++)
- if (pExaScr->prepare_access[i] == pPixmap)
+/* Handle repeated / nested calls. */
+for (i = 0; i < EXA_NUM_PREPARE_INDICES; i++) {
+ if (pExaScr->access[i].pixmap == pPixmap) {
+ pExaScr->access[i].count++;
+ return TRUE;
+ }
+}
+
+/* If slot for this index is taken, find an empty slot */
+if (pExaScr->access[index].pixmap) {
+ for (index = EXA_NUM_PREPARE_INDICES - 1; index >= 0; index--)
+ if (!pExaScr->access[index].pixmap)
break;
+}
- /* No known PrepareAccess or double prepare on the same index. */
- if (i == 6 || i == index)
- EXA_FatalErrorDebug(("EXA bug: pPixmap->devPrivate.ptr was %p, but
should have been NULL.\n",
- pPixmap->devPrivate.ptr));
+/* Access to this pixmap hasn't been prepared yet, so data pointer should
be NULL. */
+if (pPixmap->devPrivate.ptr != NULL) {
+ EXA_FatalErrorDebug(("EXA bug: pPixmap->devPrivate.ptr was %p, but
should have been NULL.\n",
+pPixmap->devPrivate.ptr));
}
offscreen = exaPixmapIsOffscreen(pPixmap);
@@ -583,8 +590,9 @@ ExaDoPrepareAccess(DrawablePtr pDrawable, int index)
else
pPixmap->devPrivate.ptr = pExaPixmap->sys_ptr;
-/* Store so we can check SRC and DEST being the same. */
-pExaScr->prepare_access[index] = pPixmap;
+/* Store so we can handle repeated / nested calls. */
+pExaScr->access[index].pixmap = pPixmap;
+pExaScr->access[index].count = 1;
if (!offscreen)
return FALSE;
@@ -662,6 +670,7 @@ exaFinishAccess(DrawablePtr pDrawable, int index)
ExaScreenPriv (pScreen);
PixmapPtr pPixmap = exaGetDrawablePixmap (pDrawable);
ExaPixmapPriv (pPixmap);
+int i;
if (!(pExaScr->info->flags & EXA_OFFSCREEN_PIXMAPS))
return;
@@ -669,11 +678,22 @@ exaFinishAccess(DrawablePtr pDrawable, int index)
if (pExaPixmap == NULL)
EXA_FatalErrorDebugWithRet(("EXA bug: exaFinishAccesss was called on a
non-exa pixmap.\n"),);
-/* Avoid mismatching indices. */
-if (pExaScr->prepare_access[index] != pPixmap)
- EXA_FatalErrorDebug(("EXA bug: Calling FinishAccess on pixmap %p with
index %d while "
- "it should have been %p.\n", pPixmap, index,
pExaScr->prepare_access[index]));
-pExaScr->prepare_access[index] = NULL;
+/* Handle repeated / nested calls. */
+for (i = 0; i < EXA_NUM_PREPARE_INDICES; i++) {
+ if (pExaScr->access[i].pixmap == pPixmap) {
+ if (--pExaScr->access[i].count > 0)
+ return;
+ index = i;
+ break;
+ }
+}
+
+/* Catch unbalanced Prepare/FinishAccess calls. */
+if (i == EXA_NUM_PREPARE_INDICES)
+ EXA_FatalErrorDebug(("EXA bug: FinishAccess called without
PrepareAccess for pixmap 0x%p.\n",
+pPixmap));
+
+pExaScr->access[ind
Re: EXA bug: Calling FinishAccess on pixmap 0xaf06d008 with index 1 while it should have been (nil).
On Sat, 2009-07-18 at 15:25 +0200, Maarten Maathuis wrote: > I'm trying to get my system in order again, but i'll certainly have a > look once i go trough the tons of updates and everything else that > needs doing. > > So someone is using scratch GC and not finishing or preparing access > properly? No, the problem is precisely that the scratch GC usage involves Prepare/FinishAccess, with the same indices already used by ExaCheckComposite() (which can potentially use all available indices). Another possible solution might be to unwrap pScreen->CreateGC before calling the lower level ps->Composite(), see below. diff --git a/exa/exa_unaccel.c b/exa/exa_unaccel.c index 0d53b67..d7ec2f0 100644 --- a/exa/exa_unaccel.c +++ b/exa/exa_unaccel.c @@ -432,6 +432,7 @@ ExaCheckComposite (CARD8 op, exaPrepareAccess (pSrc->pDrawable, EXA_PREPARE_SRC); if (pMask && pMask->pDrawable != NULL) exaPrepareAccess (pMask->pDrawable, EXA_PREPARE_MASK); +swap(pExaScr, pScreen, CreateGC); #ifdef RENDER swap(pExaScr, ps, Composite); ps->Composite (op, @@ -448,6 +449,7 @@ ExaCheckComposite (CARD8 op, height); swap(pExaScr, ps, Composite); #endif /* RENDER */ +swap(pExaScr, pScreen, CreateGC); if (pMask && pMask->pDrawable != NULL) exaFinishAccess (pMask->pDrawable, EXA_PREPARE_MASK); if (pSrc->pDrawable != NULL) -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: EXA bug: Calling FinishAccess on pixmap 0xaf06d008 with index 1 while it should have been (nil).
On Sat, 2009-07-18 at 09:23 +0200, Maarten Maathuis wrote: > Hmm, that is really funny. > > I just got home again and you are one of many who has reported these warnings. > > You are sure a mesa update was the thing to fix it? Maarten, the Prepare/FinishAccess tracking code you added to EXA breaks with current Git because pixman now uses a scratch GC in some cases, e.g. from fbComposite(). See e.g. http://bugs.freedesktop.org/show_bug.cgi?id=22822 . I attached a patch there which just disables the tracking code, maybe you can come up with a better solution. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Radeon KMS testing ( RV280 )
On Tue, 2009-07-14 at 15:26 +1000, Dan wrote: > > I've finally built a 2.6.31-rc kernel that boots. Not sure what's been > going on there. Anyway, I've been keen to test KMS & TTM stuff. > Unfortunatley, it's a double no-go. > > When the radeon module loads ( I assume for flicker-free boot, I'll > have to build it into the kernel, and not as a module ), the screen > goes black, and I get a warning that the current mode is out of range. > Is there some kernel arg to override the default settings? Should the > radeon module already be detecting supported modes? > > Next, when X tried to load, it crashes ( with a very corrupted image - > didn't switch back to the console and give me 'current mode out of > range' error ... should it? ). See log at: > http://entropy.homelinux.org/Xorg.KMS.log Check dmesg for drm or agp related output. If it looks like AGP is failing, try reducing the radeon.agpmode parameter value, in the worst case down to -1 to disable AGP. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: WM stops the X process
On Fri, 2009-07-10 at 08:51 -0700, Sebastian Glita wrote: > > - Original Message > From: Michel Dänzer > To: Sebastian Glita > Cc: xorg@lists.freedesktop.org > Sent: Friday, July 10, 2009 9:38:05 AM > Subject: Re: WM stops the X process > > > And there's no information about the crash in the log files? If so, > > check the X server process stderr output for information. > > Checking stderr output goes a step forward. Using startx -- /usr/bin/Xorg > -verbose 4 echoes these last lines on 2 computers: > > nVidia QP: > Xorg: pixman-region.c:372: pixman_region_copy: Assertion > `pixman_region_selfcheck (src)' failed. See http://bugs.freedesktop.org/show_bug.cgi?id=22642 . -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: WM stops the X process
On Thu, 2009-07-09 at 11:07 -0700, Sebastian Glita wrote: > > After some updates since last commits to libX11, X resets after a very short > period of lo. > > Using past configuration that launch a ROX session exhibits this behavior. > > So after removing .xinitrc and .xsession, in this setting where no session > commences, an xterm window opens. > Launching startfluxbox kills X (because after deleting /var/log/Xorg.log.old, > launching X, resetting X and logging anew, the *.old log appears). > Launching mwm embellish the xterm window but moving it kills X. > Launching twm seems to work a great period of time, but some actions did lead > to resetting X again. And there's no information about the crash in the log files? If so, check the X server process stderr output for information. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xorg-server 1.6.1.902
On Thu, 2009-07-02 at 09:27 -0700, Keith Packard wrote: > On Thu, 2009-07-02 at 12:48 +0200, Michel Dänzer wrote: > > > You're probably right, glad it's not really an ABI breakage after all. > > Did you see the patch I proposed to fix the ABI breakage and provide > both interfaces? Testing would be greatly appreciated as I only have > Intel hardware these days... I'm not affected by the problem, you should ask the Debian users of your driver for testing. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xorg-server 1.6.1.902
On Tue, 2009-06-30 at 13:04 -0700, Ian Romanick wrote: > > Michel Dänzer wrote: > > On Mon, 2009-06-29 at 16:03 -0700, Keith Packard wrote: > >> Thanks to Ajax for moving the DRI2 changes into the 1.6 branch, now I've > >> pulled the remaining queued patches and have pushed this as 1.6.1.902 > >> (1.6.2 RC2). If no-one finds any catastrophic bugs, [...] > > > > How about: The DRI2 changes seem to break the video driver ABI, and > > apparently Mesa without corresponding changes (which will only be in the > > upcoming 7.5 release) as well. See Brice Goglin's report from a couple > > of days ago. > > > > You rejected backports before based on breaking ABI. > > > > Don't get me wrong, I like the functionality those DRI2 changes fix, but > > surely they could have been done without breaking about every binary > > interface involved. If the video driver ABI won't be restored, this > > Actually, the bug in question could not. This was discussed quite a bit > on the mailing list and on IRC. The original DRI2 interface was > deficient and could not be made to work. So I fixed it. > > > should be reflected by bumping its major version, and the changes > > breaking it should wait for the next major release like other such > > changes. > > The change is in the DRI2 interface, and that version was changed. > Without the corresponding updates the only thing you lose is DRI2. > Reverting to DRI1 should still work. Since this affects only the Intel > driver, and we will have a fixed driver release around the same time as > the X server release, I don't think this is a catastrophic problem. You're probably right, glad it's not really an ABI breakage after all. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [ANNOUNCE] xorg-server 1.6.1.902
On Mon, 2009-06-29 at 16:03 -0700, Keith Packard wrote: > Thanks to Ajax for moving the DRI2 changes into the 1.6 branch, now I've > pulled the remaining queued patches and have pushed this as 1.6.1.902 > (1.6.2 RC2). If no-one finds any catastrophic bugs, [...] How about: The DRI2 changes seem to break the video driver ABI, and apparently Mesa without corresponding changes (which will only be in the upcoming 7.5 release) as well. See Brice Goglin's report from a couple of days ago. You rejected backports before based on breaking ABI. Don't get me wrong, I like the functionality those DRI2 changes fix, but surely they could have been done without breaking about every binary interface involved. If the video driver ABI won't be restored, this should be reflected by bumping its major version, and the changes breaking it should wait for the next major release like other such changes. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86-video-intel: man/intel.man src/i830_driver.c src/i830.h
On Wed, 2009-06-24 at 10:33 +0200, Michel Dänzer wrote:
> On Tue, 2009-06-23 at 15:06 -0700, Jesse Barnes wrote:
> > @@ -2663,10 +2665,23 @@ I830ScreenInit(int scrnIndex, ScreenPtr pScreen,
> > int argc, char **argv)
> > pI830->fb_compression = FALSE;
> > }
> >
> > + /* SwapBuffers delays to avoid tearing */
> > + pI830->swapbuffers_wait = TRUE;
> > +
> > + /* Allow user override if they set a value */
> > + if (xf86IsOptionSet(pI830->Options, OPTION_SWAPBUFFERS_WAIT)) {
> > + if (xf86ReturnOptValBool(pI830->Options, OPTION_SWAPBUFFERS_WAIT,
> > FALSE))
> > + pI830->swapbuffers_wait = TRUE;
> > + else
> > + pI830->swapbuffers_wait = FALSE;
> > + }
>
> FYI, the xf86IsOptionSet() call is superfluous. xf86ReturnOptValBool()
> returns its last argument (the default value) if the option isn't set in
> the config file. So you could simplify the code added above to
>
>/* SwapBuffers delays to avoid tearing */
>pI830->swapbuffers_wait = xf86ReturnOptValBool(pI830->Options,
> OPTION_SWAPBUFFERS_WAIT, FALSE);
Actually the default value should be TRUE of course - the default values
in your code are mixed, and I just copied & pasted the
xf86ReturnOptValBool call.
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86-video-intel: man/intel.man src/i830_driver.c src/i830.h
On Tue, 2009-06-23 at 15:06 -0700, Jesse Barnes wrote:
> @@ -2663,10 +2665,23 @@ I830ScreenInit(int scrnIndex, ScreenPtr pScreen, int
> argc, char **argv)
> pI830->fb_compression = FALSE;
> }
>
> + /* SwapBuffers delays to avoid tearing */
> + pI830->swapbuffers_wait = TRUE;
> +
> + /* Allow user override if they set a value */
> + if (xf86IsOptionSet(pI830->Options, OPTION_SWAPBUFFERS_WAIT)) {
> + if (xf86ReturnOptValBool(pI830->Options, OPTION_SWAPBUFFERS_WAIT,
> FALSE))
> +pI830->swapbuffers_wait = TRUE;
> + else
> +pI830->swapbuffers_wait = FALSE;
> + }
FYI, the xf86IsOptionSet() call is superfluous. xf86ReturnOptValBool()
returns its last argument (the default value) if the option isn't set in
the config file. So you could simplify the code added above to
/* SwapBuffers delays to avoid tearing */
pI830->swapbuffers_wait = xf86ReturnOptValBool(pI830->Options,
OPTION_SWAPBUFFERS_WAIT, FALSE);
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Current tinderbox regression (pixman, ppc64)
On Mon, 2009-06-22 at 23:53 -0400, Chris Ball wrote:
> http://tinderbox.x.org/builds/2009-06-23-0002/logs/pixman/#build
>
> pixman-fast-path.c: In function 'Store24':
> pixman-fast-path.c:69: error: invalid operands to binary * (have 'int'
> and 'uint8_t *')
>
The patch below fixes this.
diff --git a/pixman/pixman-fast-path.c b/pixman/pixman-fast-path.c
index 48c9a87..7d3f0c0 100644
--- a/pixman/pixman-fast-path.c
+++ b/pixman/pixman-fast-path.c
@@ -65,7 +65,7 @@ Store24 (uint8_t *a, uint32_t v)
else
{
#ifdef WORDS_BIGENDIAN
- *(uint16_t *)a = (uint16_t)(v >> 8)
+ *(uint16_t *)a = (uint16_t)(v >> 8);
*(a + 2) = (uint8_t)v;
#else
*(uint16_t *)a = (uint16_t)v;
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Pegasos II + Radeon 9000: No DRI and wrong colours for OpenGL
On Sun, 2009-06-14 at 20:48 +0200, Johannes Geiss wrote:
>
> I did a little investigation of this problem and saw this:
>
> xorg-server-1.5.3-r6 has a library called libglx.so. This library uses
>
> drmOpenOnce(NULL, "pci:0001:01:08.0", ...)
>
> to get the graphics card.
>
> lspci reports
>
> 0001:01:08.0 VGA compatible controller:
> ATI Technologies Inc Radeon RV250 If [Radeon 9000] (rev 01)
>
> So the PCI Bus ID seems to be correct.
>
> libdrm-2.4.5 has the function drmOpenOnce(). This function goes down to
> drmOpen(NULL, "pci:0001:01:08.0") and
> drmOpenByBusid("pci:0001:01:08.0").
>
> Now drmGetBusid(fd) is called and returns "pci::01:08.0". Which is
> wrong, because it differs from the original PCI Bus ID. So my graphics
> card will not be used with hardware accelerated OpenGL.
>
> drmGetBusid() calls the kernel module drm via IOCTL
> DRM_IOCTL_GET_UNIQUE. (see file drm_ioc32.c). So is it a bug in the
> kernel?
Yes, due to the traditional inability of userspace to deal with PCI
domains != 0, the kernel DRM macro drm_get_pci_domain() in drmP.h is
still hardcoded to 0. This needs to be fixed now; the problem is that
just fixing the macro would break old userspace, a proper fix will need
to involve DRM userspace interface versioning.
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Is there the possibility to support EXA for legacy S3 chips?
On Thu, 2009-06-04 at 19:54 +0400, Evgeny M. Zubok wrote: > Michel Dänzer writes: > > >> EXA bug: Calling FinishAccess on pixmap 0x9278d68 with index 1 while > >> it should have been (nil). > > > > This may indeed be a bug, Maarten? Might be interesting to see gdb > > backtraces for when these trigger. > > Is the https://bugs.freedesktop.org/show_bug.cgi?id=20212 relevant? Possibly. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Is there the possibility to support EXA for legacy S3 chips?
On Thu, 2009-05-28 at 15:07 +0400, Evgeny M. Zubok wrote: > Ville Syrjälä writes: > > > Just set the alignment to your fixed pitch value and it should work, > > shouldn't it? > > Great! Good idea! I have tried to set up pitch align > > pEXA->pixmapPitchAlign = pScrn->displayWidth * pS3->s3Bpp; > > and got almost normal working screen (with artefacts though) but not so > ugly as before. I think that it may be bug somewhere in EXA or driver > bacause server's log is full of error messages. > > ... > > EXA bug: Calling FinishAccess on pixmap 0x9278d68 with index 1 while it > should have been (nil). This may indeed be a bug, Maarten? Might be interesting to see gdb backtraces for when these trigger. > However the main problem with this method is that memory manager doesn't > effectively use the offscreen in this case. Indeed, I'm afraid EXA just doesn't offer any advantages over XAA for such limited hardware. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86-video-intel: 2 commits - src/drmmode_display.c src/i830_exa.c src/i830.h src/i830_memory.c src/i830_video.c
On Tue, 2009-05-19 at 10:09 -0700, Eric Anholt wrote:
> commit 34660fd2df5d61b77ed7041d32ac29053fc94f5a
> Author: Eric Anholt
> Date: Fri May 15 23:21:05 2009 -0700
>
> Only sync XV to vblank when drawing to the frontbuffer.
>
> This fixes emitting syncs to random pipes with boxes bigger than that
> pipe's vertical, leading to GPU hangs.
>
> Bug #21738
>
> diff --git a/src/i830_video.c b/src/i830_video.c
> index 1c3a5b7..6fec8ff 100644
> --- a/src/i830_video.c
> +++ b/src/i830_video.c
> @@ -2495,13 +2495,15 @@ I830PutImage(ScrnInfoPtr pScrn,
> if (sync) {
> BoxPtr box;
> int y1, y2;
> -int pipe, event, load_scan_lines_pipe;
> -
> - if (pI830->use_drm_mode)
> - pipe = drmmode_get_pipe_from_crtc_id(pI830->bufmgr, crtc);
> - else {
> - I830CrtcPrivatePtr intel_crtc = crtc->driver_private;
> - pipe = intel_crtc->pipe;
> + int pipe = -1, event, load_scan_lines_pipe;
> +
> + if (pPixmap != pScreen->GetScreenPixmap(pScreen)) {
> + if (pI830->use_drm_mode)
> + pipe = drmmode_get_pipe_from_crtc_id(pI830->bufmgr, crtc);
> + else {
> + I830CrtcPrivatePtr intel_crtc = crtc->driver_private;
> + pipe = intel_crtc->pipe;
> + }
This seems to do the opposite of what the commit message says, i.e. only
sync when not drawing to the front buffer.
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: ATI +Gnome + CompizFusion = X crash
On Sat, 2009-05-16 at 12:32 +, Felipe Lotas Asta wrote: > > Gnome 2.26.1 > xorg-server 1.6.1-1 > xorg-server-utils 7.4-6 > compiz-fusion-plugins-main 0.8.2-1 > compiz-fusion-plugins-extra 0.8.2-1 > ATI Mobility Radeon X1400 > xf86-video-ati 6.12.2-2 Which version of Mesa? > The problem is that Compiz is very unstable. Some weeks ago it was > working smoothly. Then came some Xorg, xf86-video-ati and Compiz > updates > all of a sudden and compiz started to crash very frequently, logging > me > out to GDM. Then came some more updates and thing has become better > but > still is crashing. Facts: > > 1. Starting Gnome session with Compiz-fusion but without Fusion-icon > works for a while. Then, suddenly, X crashes and I get back to GDM. [...] > 3. No error messages on Xorg.log. Are you sure you looked at the log file from the crashed X server? When another server starts afterwards, it moves the existing log file to Xorg.0.log.old. If there's really nothing about the crash in the log file, you can also check the gdm log file or the dmesg output. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: fbdev is unsuitable for EXA?
On Thu, 2009-04-23 at 16:20 +0800, jetta wrote: > Hi, all > My processor hava a 2D accelerator, so I want to add EXA support to > Xorg's fbdev driver. > But the following link says that fbdev is unsuitable for EXA. > http://xorg.freedesktop.org/wiki/ExaStatus > I do not quiet understand this. Is this means that my plan is > impossible? No, it's just that EXA doesn't make sense for the stock fbdev driver because it doesn't support any hardware acceleration. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [Intel-gfx] [ANNOUNCE] xf86-video-intel 2.6.99.903
On Fri, 2009-04-17 at 09:45 +0200, Tino Keitel wrote: > On Fri, Apr 17, 2009 at 09:03:54 +0200, Michel Dänzer wrote: > > [...] > > > Note that for fullscreen video, you can enable the compiz option > > 'Unredirect Fullscreen Windows'. I think at least kwin and xfwm4 support > > this as well. > > At least in Xfce 4.6 an mplayer in full screen shows tearing with the > option "Display fullscreen overlay windows directly" enabled in the > Xfce window manager settings. Assuming you get no tearing with compositing disabled, probably xfwm4 doesn't consider the mplayer window 'fullscreen'. I used to have the same problem with a few apps with compiz (though it also allows unredirecting windows manually with the 'Extra WM Actions' plugin), but it seems quite reliable now. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [Intel-gfx] [ANNOUNCE] xf86-video-intel 2.6.99.903
On Thu, 2009-04-16 at 17:56 +0100, Barry Scott wrote: > Carl Worth wrote: > > On Thu, 2009-04-16 at 12:34 +0100, Jonathan Miles wrote: > > > >> Okay, understood... that is strange. I am using Compiz (0.8.2 + whatever > >> Ubuntu patches it with). > >> > >> I'm going to pull the latest git trees later and start looking into this > >> in more detail. > >> > > > > Thanks for your willingness to help, Jon. > > > > I don't know exactly how compiz interacts with xv, but you certainly > > might start by trying without compiz running to see if the tearing > > behavior changes, (my xv tests were without compiz). > > > The code you have to prevent tearing will only work without compositing. Note that for fullscreen video, you can enable the compiz option 'Unredirect Fullscreen Windows'. I think at least kwin and xfwm4 support this as well. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: PseudoColor and DirectColor visuals (was Re: Documentation?)
On Thu, 2009-04-09 at 11:17 -0400, Peter Harris wrote: > Patrick O'Donnell wrote: > > > (Supporting TrueColor, alas, would be a royal pain, given the design > > of the apps.) > > At least one app I've seen would use an OpenGL fragment shader to do the > PseudoColor => TrueColor translation at CopyArea[1] time. Instead of > calling XStoreColors, you would load a new 1D texture and redo the copy. > Unfortunately, I don't know of a way to bind an X Pixmap into an OpenGL > texture, so that may not help you any. FWIW, the GLX extension GLX_EXT_texture_from_pixmap allows binding a pixmap into an OpenGL texture. It was designed for and is mostly used by compositing managers like compiz which use OpenGL, but AFAICT it should be usable for this idea. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xorg-server-1.5.3 + xf86-video-intel-2.6.3 is slow at 2D
On Wed, 2009-04-08 at 22:09 +0300, Mihai Donțu wrote:
>
> Until yesterday, I was using the xorg server 1.3.0. I was very satisfied with
> it, but my distribution (Gentoo) moved 1.5.3 into stable and I had to
> upgrade. The problem that is most annoying to me is that everything in
> konsole (KDE's terminal emulator) is drawn considerably slow. I can see how
> mc builds its ui. It happens that I'm very sensitive at how my desktop moves
> in 2D (I'm not a 3D fan). I've tried using XAA instead of EXA, but that did
> not help. Is there anything I can do to speed up the 2D ops?
If Gentoo hasn't backported xserver commit
f07f18231a921d3ae9dd9b75881c9e58e9e2e235 ('EXA: Allow using
exaCompositeRects also when we can't use a mask in exaGlyphs.') yet,
that could be worth a shot. (Note that
265d20068af5434489752b6dba0bf0065b3cc3ec is also required to fix a
little bug in that)
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
On Wed, 2009-04-08 at 10:30 -0400, Patrick O'Donnell wrote: > >From: Michel =?ISO-8859-1?Q?D=E4nzer?= > >Date: Wed, 08 Apr 2009 15:58:18 +0200 > > > >On Wed, 2009-04-08 at 09:55 -0400, Patrick O'Donnell wrote: > >> >From: Michel =?ISO-8859-1?Q?D=E4nzer?= > >> >Date: Wed, 08 Apr 2009 15:29:28 +0200 > >> > > >> >On Wed, 2009-04-08 at 09:14 -0400, Patrick O'Donnell wrote: > >> >> Unfortunately, that's not going to be available for all the platforms > >> >> we must support. > >> > > >> >Why not? > >> > >> U... Because the servers on those platforms do not offer it? > > > >What are 'those platforms'? Which X.org servers offer neither the > >Composite extension nor backing store? > > The world is not all X.org. Not all the X servers on Windows that we > have to deal with offer the Composite extension (or backing store -- > sigh). Ah, I thought this was about X.org changes making things worse for you. Guess I lost track. :} -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
On Wed, 2009-04-08 at 09:55 -0400, Patrick O'Donnell wrote: > >From: Michel =?ISO-8859-1?Q?D=E4nzer?= > >Date: Wed, 08 Apr 2009 15:29:28 +0200 > > > >On Wed, 2009-04-08 at 09:14 -0400, Patrick O'Donnell wrote: > >> Unfortunately, that's not going to be available for all the platforms > >> we must support. > > > >Why not? > > U... Because the servers on those platforms do not offer it? What are 'those platforms'? Which X.org servers offer neither the Composite extension nor backing store? -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
On Wed, 2009-04-08 at 09:14 -0400, Patrick O'Donnell wrote: > >From: Michel =?ISO-8859-1?Q?D=E4nzer?= > >Date: Wed, 08 Apr 2009 09:42:01 +0200 > > > >On Tue, 2009-04-07 at 16:27 -0400, Patrick O'Donnell wrote: > >> One of our applications has a very expensive redraw cycle that we now > >> have to decide how we are going to manage when backing store is not > >> being supplied. > > > >If you can enable compositing (even just xcompmgr -a), that might be the > >simplest solution. > > Yes, I do need to look in to compositing as a possible solution. > Unfortunately, that's not going to be available for all the platforms > we must support. Why not? -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Documentation?
On Tue, 2009-04-07 at 16:27 -0400, Patrick O'Donnell wrote: > > >There shouldn't be any breakage of compatibility in old old apps. ... > > Perhaps not compatibility, strictly speaking, but we're going to miss > our old friends backing store and save unders. Their demise feels > like a breakage of compatibility, as the X servers we've used have all > had reasonably aggressive offering of the optimizations (til now). > (We have been strongly depending on their existence, incorrectly.) > One of our applications has a very expensive redraw cycle that we now > have to decide how we are going to manage when backing store is not > being supplied. If you can enable compositing (even just xcompmgr -a), that might be the simplest solution. Or, someone who cares about backing store could work on improving the new implementation layered on top of composite... -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [RFC] glx: fix DRI2 memory leak
On Mon, 2009-04-06 at 14:57 -0700, Jesse Barnes wrote: > On Wed, 01 Apr 2009 17:46:08 +0200 > Michel Dänzer wrote: > > The real problem was pointed out by Pierre Willenbrock: If > > glxPriv->pDraw is a pixmap, DrawableGone() destroys it, then later > > DRI2DestroyDrawable dereferences it... The patch below seems to work > > here - at least it hasn't crashed in a couple of hours, not sure about > > the leak yet. > > > > Note that unless I'm missing something, it might still be possible for > > this to occur with windows if the underlying DrawableRec is freed > > before this code is reached. > > > > Also, I don't really understand the logic behind clearing > > glxPriv->pDraw and ->drawId here. In particular, I'm not sure > > DrawableGone will ever be called with glxPriv->refCount > 1. If it > > won't, this change makes the assignments unreachable. And if it will, > > we'll again leak because the cleanup code won't be able to get to the > > underlying DrawableRec? > > So are you happy enough with this fix to push it, Michel? Memory usage > is still high on Intel after the fix, but that may be due to bo > caching, and this is an important fix... Feel free to push it. It's not really my fix, I just combined the fixes and suggestions from others. :) -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: [RFC] glx: fix DRI2 memory leak
t;pScreen;
+PixmapPtr pPixmap = NULL;
+int refcount;
switch (glxPriv->type) {
case GLX_DRAWABLE_PIXMAP:
case GLX_DRAWABLE_PBUFFER:
- (*pScreen->DestroyPixmap)((PixmapPtr) glxPriv->pDraw);
+ pPixmap = (PixmapPtr) glxPriv->pDraw;
break;
}
-glxPriv->pDraw = NULL;
-glxPriv->drawId = 0;
+refcount = glxPriv->refCount;
__glXUnrefDrawable(glxPriv);
+if (refcount > 1) {
+ glxPriv->pDraw = NULL;
+ glxPriv->drawId = 0;
+}
+
+if (pPixmap)
+ (*pScreen->DestroyPixmap)(pPixmap);
return True;
}
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
Re: r200 exa performance regression in xserver-1.6?
On Thu, 2009-03-26 at 16:15 +1100, Daniel Kasak wrote: > > So anyway, I'm running ecomorph ( compiz port for E17 ), and most of the > effects are very slow and jumpy. > > I did a quick sysprof test while switching desktops, and it looks like > it's all in memcpy: > > miClearToBackground 0.00 77.45 > miPaintWindow 0.00 77.45 > ValidateGC 0.00 77.45 > In file /usr/bin/Xorg 0.00 77.45 > In file /usr/lib/xorg/modules/libexa.so 0.00 77.45 > exaPrepareAccessGC0.00 77.45 > exaPrepareAccess0.00 77.45 > exaPrepareAccessReg 0.00 77.45 > exaDoMigration 0.00 77.45 > In file /usr/lib/xorg/modules/libexa.so 0.00 77.45 > memcpy 77.45 77.45 Unfortunately the EXA module is missing debugging symbols, so it isn't entirely clear what's going on. Would be interesting to see a new profile with that fixed. It might also be worth trying EXA from the xserver Git master branch. exaValidateGC has been reworked quite a bit, and there's a chance your use case could have improved. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: How to shift color bits in fbdev?
On Son, 2009-03-15 at 11:08 -0700, Gregoire Gentil wrote: > > - the background is still with a darken opacity > - the problem around the transparent icons have disappeared > - the png background of the bottom panel has the exact perfect colors > (no opacity problem) and it's a complex png shading background. > - The icons in the start menu have 95% of the right colors. FWIW, if you aren't going to use hardware acceleration, then the shadow layer (and fixing up the pixel format in the shadowUpdate hook) is probably a better solution than wfb. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: SGI O2 kernel fb driver vs Xserver
On Sun, 2009-03-08 at 18:17 +0300, Андрей Рандрианасулу wrote: > > -Original Message- > From: Андрей Рандрианасулу > To: xorg@lists.freedesktop.org > Date: Sun, 08 Mar 2009 15:00:32 +0300 > Subject: SGI O2 kernel fb driver vs Xserver > > > Hi list! > > > > I have SGI O2 workstation, and gentoo Linux distro > > installed in root-on-NFS mode. Kernel - self-compiled 2.6.29-rc5-0300 (with > > gcc-4.3.3), system was mostly recompiled with glibc-2.9, gcc 4.3.3, > > binutils 2.19.1. Console apps works fine, in framebuffer mode > > (1024x768...@75, allocation of 4mb RAM was defined at compile time). > > > > But xserver (1.5.3 + gentoo patches) gives me error: > > > > (EE) FBDEV(0): FBIOPUT_VSCREENINFO succeeded but modified mode > > > > (EE) FBDEV(0): mode initialization failed > > > > I think this msg comes from hw/xfree86/fbdevhw/fbdevhw.c and was added in > > late 2006 > > > > commit f6815cb68b0f6698497348fc6e4214dacef33b95 > > Author: Michel DÃ?nzer > > Date: Sat Dec 30 10:18:28 2006 +0100 > > > > fbdevhw: Consolidate modeset ioctl calling, report failure if it > > modifies mo > > de. > > > > Google points me at https://bugzilla.novell.com/show_bug.cgi?id=285523 , > > i'm in process of rebuilding xserver (just 1.5.3, without gentoo-specific > > patches) with debug set to 1. If i run into same kind of bug - it should be > > fixed on kernel (fb driver) side? > > > > i'll open freedesktop.org bug with additional info, when compilation > > finishes ... > > (at least some kernel fb drivers give very same error message - > > http://www.mail-archive.com/debian-...@lists.debian.org/msg09406.html) > > small update - > > sgio2 xorg-server-1.5.3 # X > > X.Org X Server 1.5.3 > Release Date: 5 November 2008 > X Protocol Version 11, Revision 0 > Build Operating System: Linux 2.6.29-rc6-00217-g823b387 mips64 > Current Operating System: Linux sgio2 2.6.29-rc6-00217-g823b387 #11 Tue Mar 3 > 13:52:25 GMT 2009 mips64 > Build Date: 08 March 2009 01:06:00PM > > Before reporting problems, check http://wiki.x.org > to make sure that you have the latest version. > Markers: (--) probed, (**) from config file, (==) default setting, > (++) from command line, (!!) notice, (II) informational, > (WW) warning, (EE) error, (NI) not implemented, (??) unknown. > (==) Log file: "/usr/var/log/Xorg.0.log", Time: Sun Mar 8 17:38:05 2009 > (==) Using config file: "/etc/X11/xorg.conf" > (EE) Failed to load module "summa" (module does not exist, 0) > fbdevHW: Init 0 > fbdevHW: VerifyModes 0 > fbdevHW: UseBuildinMode 0 > fbdevHW: MapVidmem 0 > fbdevHW: LinearOffset 0 > fbdevHW: Save 0 > fbdevHW: SetMode 0 > xfree init mode:25172 640 657 753 800 480 491 493 525 > fbdev init mode:39726 640 17 96 47 480 11 2 32 32 8:8:8 > (EE) FBDEV(0): FBIOPUT_VSCREENINFO succeeded but modified mode > fbdev returned mode:39726 640 18 96 46 480 12 2 31 32 8:8:8 > (EE) FBDEV(0): mode initialization failed It does look like the kernel framebuffer device may be broken, though you could also try xserver 1.6, some of these checks have been relaxed a little. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: compiz and xorg-server 1.6.0
On Thu, 2009-02-26 at 18:38 +0100, Julien Cristau wrote: > On Thu, Feb 26, 2009 at 01:38:25 +, Colin Guthrie wrote: > > > 'Twas brillig, and Colin Guthrie at 23/02/09 09:38 did gyre and gimble: > > > In the end the "fix" I found was to revert: > > > http://cgit.freedesktop.org/xorg/xserver/commit/?h=server-1.6-branch&id=444127f9f408d2f517fdfab0092bd67b29073373 > > > > > > Before this, compiz would start but give a white screen on the cube > > > face. More intelligent scripts would probably stop it starting in the > > > first place. > > > > Sadly it seems the above was missed in the 1.6.0 release. Perhaps this > > commit can be looked at for 1.6.1? > > > Open a bugzilla and mark it as a blocker for 1.6.1. Otherwise it > doesn't exist... The DRI1 GLX_EXT_texture_from_pixmap regression caused by the above commit was fixed for 1.6 final in commit e96921ca954ff0d3de8a69cea085aac2d43b0a2e . -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Howto set a modeline for fbdev driver?
On Mon, 2009-02-16 at 15:03 +0100, Hans J. Koch wrote: > I'm using X on top of fb using xserver-xorg-video-fbdev from latest Debian > sid. It's some embedded device (armel) and uses an 800x480 TFT with strange > timings. A framebuffer console works fine, I've got the fb device itself > setup correctly. > But if I start X, instead of simply copying the correct values, X insists on > calculating its own, which don't work (vsync much too short). It should only do that if your xorg.conf has a SubSection "Display" with a Modes line. If you don't have that, please provide the full xorg.conf and corresponding Xorg.0.log. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: xf86-video-ati: [PATCH] Janitor: make distcheck, .gitignore.
First of all, radeon driver development discussion takes place on the xorg-driver-ati list. Moving there. On Thu, 2009-02-05 at 21:23 -0200, Paulo César Pereira de Andrade wrote: > I am starting to believe that, maybe -Wpointer-arith should > not only be out of $CWARNFLAGS, but that $CWARNFLAGS should > actually include -Wno-pointer-arith. > Almost every "casting" is a sign of something going wrong, > as the compiler should always able to do proper type > conversion automatically, I made sure the driver builds for me with -Wall a while ago, and have been building with -Wall -Werror since. I'm not sure I like the idea of enabling even more warnings, especially as apparently none of them have pointed out a real bug? > and changing the void *'s in the ati driver to something like an > "unsigned char *" just to correct that warning may not be the proper > solution. Are you referring to arithmetic on void* pointers? That's a gccism, so if we have that we may want to fix it. -- Earthling Michel Dänzer |http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer ___ xorg mailing list xorg@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/xorg
Re: Not solved!
On Thu, 2009-02-05 at 18:43 +, Nix wrote:
> On 5 Feb 2009, Michel Dänzer verbalised:
>
> > EXA offscreen memory is probably fragmented. I have a defragmentation
> > patch that I hope to clean up and push one of these days.
>
> A kludgy approach would be to do whatever gets done on VT switch (dump
> and repopulate the entirety of EXA offscreen memory?) whenever a
> significant fraction of allocation requests start to fail due to
> fragmentation.
Yeah, but I implemented something fancier. :) Care to try the attached
patch?
> It certainly doesn't log anything about this case. Right now the only
> EXA-related message I see in the logs after X startup is a single lonely
>
> exaCopyDirty: Pending damage region empty!
>
> which is presumably unrelated.
Right, I pushed a change to guard this by a debugging #define.
P.S. Moving to the xorg-devel list.
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
EXA: Defragment offscreen memory.
From:
At most once per second, under the following circumstances:
* We can't satisfy an offscreen memory allocation, but there seems to be enough
offscreen memory available in total.
* The server is going idle.
---
exa/exa.c | 24 ++
exa/exa.h |2
exa/exa_offscreen.c | 211 +--
exa/exa_priv.h |5 +
4 files changed, 235 insertions(+), 7 deletions(-)
diff --git a/exa/exa.c b/exa/exa.c
index ba063bb..9d3c4bf 100644
--- a/exa/exa.c
+++ b/exa/exa.c
@@ -744,6 +744,8 @@ exaCloseScreen(int i, ScreenPtr pScreen)
if (ps->Glyphs == exaGlyphs)
exaGlyphsFini(pScreen);
+if (!pExaScr->info->CreatePixmap)
+ pScreen->BlockHandler = pExaScr->SavedBlockHandler;
pScreen->CreateGC = pExaScr->SavedCreateGC;
pScreen->CloseScreen = pExaScr->SavedCloseScreen;
pScreen->GetImage = pExaScr->SavedGetImage;
@@ -769,6 +771,23 @@ exaCloseScreen(int i, ScreenPtr pScreen)
return (*pScreen->CloseScreen) (i, pScreen);
}
+static void
+ExaBlockHandler(int screenNum, pointer blockData, pointer pTimeout,
+ pointer pReadmask)
+{
+ScreenPtr pScreen = screenInfo.screens[screenNum];
+ExaScreenPriv(pScreen);
+
+/* Try and keep the offscreen memory area tidy every now and then when we're
+ * going idle anyway.
+ */
+ExaOffscreenDefragment(pScreen);
+
+pScreen->BlockHandler = pExaScr->SavedBlockHandler;
+(*pScreen->BlockHandler) (screenNum, blockData, pTimeout, pReadmask);
+pScreen->BlockHandler = ExaBlockHandler;
+}
+
/**
* This function allocates a driver structure for EXA drivers to fill in. By
* having EXA allocate the structure, the driver structure can be extended
@@ -896,6 +915,11 @@ exaDriverInit (ScreenPtr pScreen,
pExaScr->SavedCloseScreen = pScreen->CloseScreen;
pScreen->CloseScreen = exaCloseScreen;
+if (!pExaScr->info->CreatePixmap) {
+ pExaScr->SavedBlockHandler = pScreen->BlockHandler;
+ pScreen->BlockHandler = ExaBlockHandler;
+}
+
pExaScr->SavedCreateGC = pScreen->CreateGC;
pScreen->CreateGC = exaCreateGC;
diff --git a/exa/exa.h b/exa/exa.h
index 21a0f1a..c48a582 100644
--- a/exa/exa.h
+++ b/exa/exa.h
@@ -64,7 +64,9 @@ struct _ExaOffscreenArea {
ExaOffscreenState state;
ExaOffscreenArea*next;
+ExaOffscreenArea*prev;
+int align; /* required alignment */
unsignedeviction_cost;
};
diff --git a/exa/exa_offscreen.c b/exa/exa_offscreen.c
index 4aaa2c1..d3e015f 100644
--- a/exa/exa_offscreen.c
+++ b/exa/exa_offscreen.c
@@ -172,7 +172,7 @@ exaOffscreenAlloc (ScreenPtr pScreen, int size, int align,
{
ExaOffscreenArea *area;
ExaScreenPriv (pScreen);
-int tmp, real_size = 0;
+int tmp, real_size = 0, free_total = 0, largest_avail = 0;
#if DEBUG_OFFSCREEN
static int number = 0;
ErrorF("= allocating a new pixmap %d\n", ++number);
@@ -213,6 +213,27 @@ exaOffscreenAlloc (ScreenPtr pScreen, int size, int align,
/* does it fit? */
if (real_size <= area->size)
break;
+
+ free_total += area->size;
+
+ if (area->size > largest_avail)
+ largest_avail = area->size;
+}
+
+if (!area && free_total >= size) {
+ area = ExaOffscreenDefragment(pScreen);
+
+ if (area) {
+ /* adjust size to match alignment requirement */
+ real_size = size;
+ tmp = area->base_offset % align;
+ if (tmp)
+ real_size += (align - tmp);
+
+ /* does it fit? */
+ if (real_size > area->size)
+ area = NULL;
+ }
}
if (!area)
@@ -255,14 +276,27 @@ exaOffscreenAlloc (ScreenPtr pScreen, int size, int align,
if (!new_area)
return NULL;
new_area->base_o
Re: Performance of XRenderCompositeTrapezoids in the aliased case
On Tue, 2009-02-03 at 04:10 +0200, Mart Raudsepp wrote:
>
> I shamefully admit I haven't actually gotten around to pinpoint this
> glyph perf regression with 101% certainty at Pict_A8 OpAdd's, but
> logically that should be the case.
Does the attached patch help? It should promote a8 masks to argb if the
driver can't composite to a8. Beware, I only tested that it compiles and
doesn't seem to break anything else.
P.S. Moving to the xorg-devel list.
--
Earthling Michel Dänzer |http://www.vmware.com
Libre software enthusiast | Debian, X and DRI developer
EXA: If the driver can't composite to an a8 mask, try an argb mask for glyphs.
From:
---
exa/exa_glyphs.c | 36 ++--
1 files changed, 34 insertions(+), 2 deletions(-)
diff --git a/exa/exa_glyphs.c b/exa/exa_glyphs.c
index 93d78b8..937f1f3 100644
--- a/exa/exa_glyphs.c
+++ b/exa/exa_glyphs.c
@@ -706,6 +706,7 @@ exaGlyphs (CARD8 op,
PixmapPtr pMaskPixmap = 0;
PicturePtr pMask = NULL;
ScreenPtr pScreen = pDst->pDrawable->pScreen;
+ExaScreenPriv(pScreen);
int width = 0, height = 0;
int x, y;
int xDst = list->xOff, yDst = list->yOff;
@@ -744,11 +745,42 @@ exaGlyphs (CARD8 op,
pMask = CreatePicture (0, &pMaskPixmap->drawable,
maskFormat, CPComponentAlpha, &component_alpha,
serverClient, &error);
- if (!pMask)
+ if (!pMask ||
+ (PICT_FORMAT_RGB(maskFormat->format) == 0 &&
+ pExaScr->info->CheckComposite &&
+ !(*pExaScr->info->CheckComposite) (PictOpAdd, pSrc, pMask, pDst)))
{
+ PictFormatPtr argbFormat;
+
(*pScreen->DestroyPixmap) (pMaskPixmap);
- return;
+
+ if (!pMask)
+ return;
+
+ /* The driver can't composite to a8, let's try argb (but without
+ * component-alpha) */
+ FreePicture ((pointer) pMask, (XID) 0);
+
+ argbFormat = PictureMatchFormat (pScreen, 32, PICT_a8r8g8b8);
+
+ if (argbFormat)
+ maskFormat = argbFormat;
+
+ pMaskPixmap = (*pScreen->CreatePixmap) (pScreen, width, height,
+ maskFormat->depth,
+ CREATE_PIXMAP_USAGE_SCRATCH);
+ if (!pMaskPixmap)
+ return;
+
+ pMask = CreatePicture (0, &pMaskPixmap->drawable,
+ maskFormat, CPComponentAlpha,
+ &component_alpha, serverClient, &error);
+ if (!pMask) {
+ (*pScreen->DestroyPixmap) (pMaskPixmap);
+ return;
+ }
}
+
pGC = GetScratchGC (pMaskPixmap->drawable.depth, pScreen);
ValidateGC (&pMaskPixmap->drawable, pGC);
rect.x = 0;
___
xorg mailing list
xorg@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/xorg
