[PATCH] complete (I hope!) i830 EXA support
jbarnes at virtuousgeek.org
Sat Sep 10 09:20:35 PDT 2005
On Saturday, September 10, 2005 9:05 am, Bernhard Kaindl wrote:
> Dear Jesse,
> I'm not (yet) subscribed to the xorg list, but I follow it thru the
> archive since a few days.
> 1st: Great work, Xv works here on a i915 GM too!
> About Xv and transparency: I know from my Nvidia that the nvidia
> driver does not have transpacent Xv windows, the effects which I see
> are identical with all composite-accelerated drivers which I saw.
Ah, ok, I guess that's normal then. I haven't looked at Xv much so I
> Two observations:
> The Xv output window does not respond to ttransparency, with your
> driver it shows the blue X11 background of the Xv rendering area. You
> see that background also when the X11 Xv window is shown or moved but
> the Xv is not yet shown or moved by the graphics hardware.
Mine shows slightly different behavior. If I set the transparency on
the Xv window, it'll change to the background color, but then when I
move it the video comes back (though not transparently).
> When you enable window shadows thru xcompmgr and place another X11
> window with window shadows partically above the Xv output window, you
> see that in the area where the window shadow is drawn the composition
> for the shadow does not occur with the Xv output but with the blue
> X11 Xv window background.
> So appears to me that Xv's output rendering occurs completely
> separate from the X11 output (does scale and color conversion and
> renders directly to the output then), and if it's possible to render
> Xv to a normal composite window that should fix this. Of couse that
> means that as soon as composting on Xv would be neccessary, all Xv
> data would be sent back from the graphics hardware to the system
> It looks like a difficult problem, however maybe there is a solution,
> and there is not only Xv which uses a separate output pipe, but also
> hardware acceleared (direct) 3D. Since recent OpenGL allows to render
> into an offsceeen area and read the rendering results back from 3D
> engine memory to main memory, there it would be always possible to
> actually do compositing even though an separate 3D hardware pipeline
> does the creation of the window contents, because recent hardware has
> to provide for it to support these OpenGL functions and they are used
> at least in some programs.
> Xv could actually be worked around by using OpenGL or X11 output
> instead, Matthias Hopf <mhopf at suse.de> told me that he was working
> on a Xv backend which uses OpenGL for display for use in the Xglx
> server which has to provide Xv and render this Xv using OpenGL using
> it's host X server. As far as I remember he showed it working to me,
> and I think that should be done not in the driver but in the EXA code
> as an option for drivers which support EXA and DRI.
Yeah, I've seen demos that show it working as well, so it's definitely
possible (though I'm not sure if those demos used a GL video backend or
> Code which would make transparency and shadows work with DRI windows
> would be nice indeed too and would be a first step for implementing
> this and having a first feature without having to get into Xv, but
> would would proof a working concept.
Definitely. I was hoping to spend some time on Xegl next, which should
address some of those issues.
> But I have another problem right now, because when I try to open a
> DRI window with your patch and EXA and Composite enabled, I get a
> crash of the server with this message:
> i830DRISwapContext (in)
> symbol lookup error: /usr/X11R6/lib/modules/drivers/i810_drv.so:
> undefined symbol: XAAGetPatternROP
Hm, I must have missed a call to that routine, but I don't see where.
Are you using the latest version of the driver? It's at
> On the i915GM system at least, the server/i810 driver does not
> restore the text console before exiting so the screen looks like the
> system would have locked up, fortunately since swsusp, I can initate
> an suspend to disk thru the ACPI-reported sleep key combination and
> get VGA text again at the resume of the system afterwads, where the
> card is booted normally and I just have to switch back the console
> from the empty console 7 to console 1 using Ctrl-F1.
Yeah, that sounds like an old version of the driver. Maybe I attached
the wrong one?
> I hope you have a solution for the XAAGetPatternROP and probable
> subseqent XAA calls and I would be interested in that as well, I
> think this crash should be fixed before merging the patch.
So you're using the patch but using "AccelMethod" "XAA"? I've only
tested that a little, so there may be bugs when both EXA and XAA
support are compiled into the driver. If you could make sure you're
running the latest code (apply the patch again and 'make install' the
driver after doing a 'make clean') to confirm that would be great.
> Also please do a "cvs up i830_driver.c" to merge the last update
> of the driver, otherwise people which use the current CVS and try
> to apply the patch get a reject because of this change in CVS:
> 2005-09-06 Alan Hourihane <alanh at fairlite.demon.co.uk>
> * programs/Xserver/hw/xfree86/drivers/i810/i830_driver.c
> Fix DirectColor visual colormap issues at 16bpp in the i830
> The other changes do not appear to me relevant for the patch to me,
> but this one interferes with appying your patch.
Ok, thanks, I'll do that.
> Feel free to add the xorg list to the Cc with a full (or partly)
> quote of this mail if you want to discuss this with me over the list,
> I would possibly send this report and these ideas to the list myself
> later after I subscribed the list. I just want to send this to you so
> that you can react and if you have time you can possibly address the
> DRI Init -> XAA issue yourself.
Thanks a lot for testing!
More information about the xorg