anholt's lj

i855 LVDS oops
I just found out today that I had totally broken i855 LVDS support in the modesetting branch, and while fixing that, I realized that our i855 LVDS support had been pretty broken since its inception. With some digging, I found one bugzilla entry for it, but several emails. Please file more bugzilla entries for bugs, folks, and don't worry about finding the right bug to attach to -- more individual bugs means more a better chance that I'll end up fixing your bug instead of some less important one of someone else's.

So, if you're trying to use the modesetting branch on your i855 and having troubles, please try http://people.freedesktop.org/~anholt/i8xx-clocks.diff on your driver from a fresh boot, and either:

1) Tell me that it makes your system work
2) File a bugzilla with Xorg.0.log and a note that you tried this patch.

my first X extension
Today I got to implement my first X request, from design through working code. It's a simple one, but the results are nice.

Up until now, DRI clients haven't been able to report damage. As a result, screencast programs haven't been able to use XDamage to do minimal screen-scraping when GL apps are running. I added a request where you simply hand an XFixes region of the area to be damaged plus a drawable, and the server reports that damage to that drawable. The DRI drivers in cooperation with the GL library now use this at SwapBuffers time to report the drawing they do to the screen.

I tested this using gstreamer, which let me easily create a screencast that displayed on the same screen. The command I used was:

gst-launch ximagesrc ! videoscale ! video-x-raw-rgb, width=400 ! ximagesink sync=false

There was only one issue: gstreamer folks still haven't committed my improvement #342463 to ximagesrc. So if you run glxgears for example, it overwhelms ximagesrc with damage rectangles, and within a few frames it's ground to a halt trying to catch up. Someone needs to commit this (or just OK me to give myself a commit bit :) ) I ended up sticking a sleep in gears to slow things down enough for now with stock ximagesrc.

I didn't actually do this for screencasting, though that was originally why I'd thought about doing this extension. We'd run into a problem with RandR 1.2, which allows for each CRTC to have different rotation, so each CRTC may need a shadow buffer for its rotation of the framebuffer. This means the server wants more control over rotation, which was already a mess to support in the previous architecture of the DRI driver doing the shadow buffer update on its own using rotation information we jammed into the sarea. Now we can nuke a bunch of support code and do shadow updates for rotation entirely within the server, with no concern for 3D.

Next things that could be done to build on this:

Make AIGLX support the new DRI method for damage reporting so screencasters work on it, too.
Merge to server-1.3 branch once we branch that off of randr-1.2-for-server-1.2 so it hits the next X Server release after 1.2.
Fix the driver to report damage for glCopyPixels and front buffer rendering
Fix libXvMC to report damage for its direct rendering.

jhbuilding xorg
For a while people have been using various hacky scripts to build all of modular xorg. I've never liked them -- when I'm building something, I just want to update one piece, and whatever it depended on. jhbuild, therefore, has been a good tool, except that it can't deal with the Mesa build disaster without using a custom module type.

So, a while back, I went ahead and made that module type. However, getting review from jamesh by prodding on IRC has been a failure, and 4 months later it's still uncommitted. So this is a plea: Can anyone get this committed to gnome, or will I be forced to maintain a fork of jhbuild for something so trivial?

What this is blocking is coverity checking. For coverity, they want something simple to build the whole project. jhbuild would be great for that, I think, except that right now manual intervention is required to get Mesa built, and that's in the middle of building the xorg stack.

i830 is hard, let's go shopping
Spent some time again with my nemesis, the i830 laptop. With our new native modesetting, we have to know how to program every output chip on every system, and before the 915G there were a lot of chips. For the desktop ADD cards, this hasn't been hard -- look at the name on the chip, go look up the open documentation, implement, done. For laptops, it's a little uglier -- I can't see the chip without tearing the machine apart. And given that this machine is already rather flimsy, I wasn't too excited about tearing it apart and hoping it's fine after getting it back together.

I thought these laptops had Chrontel 7017 parts, generally. So a while ago, I tried writing a driver for that chip. I started it up, and I got no probe from the hardware. Hmm.

Well, I've got some BIOS source code, and each of the add-in drivers has a few strings in it. So I dumped the bios with some handy code I had, and ran strings over it. I found an instance of "ivch" and none of the other strings from drivers I had code for. So it seemed like a good guess. I found published docs, whipped up a driver, and got no probe again.

So we tried tracing what the BIOS did using mjg59/airlied's neat little tool. Unfortunately, the old driver doesn't use the same mechanism to talk to the graphics chip, so the log of the trace was rather short and uninteresting.

Then I decided to just see if I could get anything from I2C. I wrote code to try to read 1 or 2 bytes from every register of every possible slave device from every GPIO pin pair. And I got... nothing.

So today Keith and I sat down again and tried disassembling the machine's actual BIOS to try to confirm what it was doing. We confirmed that it had the ivch driver, in use, and that it was on the GPIO pair and slave address we initially expected. So we tried to run the BIOS code again just to confirm it still worked, and it can't set a video mode at all any more. And then we tried starting X with the BIOS-based modesetting driver, and that failed too now -- the backlight turns on, but nothing is displayed.

So, I think we killed our i830. Getting this one was hard -- scrounging through FreeGeek's laptop room, and finding one of them in the many 10s of laptops we looked through. I'm not sure where I'm going to get another.

Called keithp up today and asked, "if I got a merge of RandR 1.2 to master ready, should I push it?" We agreed yes -- the protocol is where we think it will be in the final release, so we're satisfied with putting it into the main development branches.

There is remaining work to do, for sure.

autoconfig stuff from xf86-video-intel hasn't been pushed to an xf86 randr generic layer.
manual config stuff hasn't been written.
more of the xf86-video-intel helpers, and ddcProperties.c code, needs to be made generic.
Some bits of protocol don't do enough on the server side (property changes don't call into the driver).
Some bits of protocol don't do enough on the client side (XRRSetCrtcGamma() is awfully short!).
modesetting of xf86-video-intel hasn't been merged to master.

However, this is a pretty big milestone. The rest can be filled in with much less inter-module versioning trouble, and in relatively short order I hope. The main thing is a protocol that we're happy with, and believe we could use to write generic desktop environment support for mode setting.

Last weekend was good fun. Friday night was nerd night (Rifts RPG) until the usual early-morning. Then Saturday there was idr's lan party. 16 people playing games in one basement. Kind of amazing, and good fun. There were some rough spots, though, such as me trying to install Windows on the new hardware to play HL2 games we had scheduled. I was really amazed once again at just how bad driver support is on Windows. I really need to look into wine on the Mac Mini (and some driver optimizations) so it can be the portable, branding-compliant gaming box.

Modesetting is continuing along. I've got CRT and SDVO outputs reliably reporting their connectedness, which is important for deciding which outputs to turn on when you've got a system with potentially 5 of them (CRT, LVDS, SDVO, SDVO, TV). RandR is slowly shaping up, and we're cutting more old cruft out of the driver. I think the next thing I'm going to do is hook up the LVDS panel fitting output property, so we've got an example of that working and can test that code path from xrandr12 all the way to the hardware. Then we need to get sensible-defaults code finished for initial output configuration, at which point we can decide if we even need to write a bunch of nasty xorg.conf support for output configuration, or can leave it up to post-startup.

I also set up a cronjob of doxygen for the X Server and xf86-video-intel on annarchy. I'd been talking about doing this since I first worked on EXA doxygen, but finally got around to it now. You can check it out at http://people.freedesktop.org/~anholt/doxygen/xorg/ for now. The xserver bits are woefully under-documented -- DMX and EXA as far as doxygen go. xf86-video-intel is getting better in the modesetting branch, I think, but I'm still not satisfied. I'm also not happy with doxygen's output in many cases, such as the struct _ExaDriver that should have been called ExaDriver, or when I want to describe a group of fields with one block of description. But I'm pretty sure it's better than nothing. If anyone else has git trees on fdo that have doxygen, I can try throwing them into my script to generate output periodically, too.

house updates, more mac mini fun
Well, I'm online at the new house. We got internet Monday morning, after shockingly short Qwest adventures (only a 4 day outage instead of a scheduled 1 day outage, which is a record for them). We were moving boxes from Friday night through Sunday, and things have now quieted down to unhurried unpacking and slow migration of furniture towards final destinations. The problem is, any moment when I need a break from work, there are still boxes waiting for me, and we're not even done cleaning the old place (which needs to be done by the 30th). Owning a home is pretty nice -- no more worries about when we're going to have to move next, and the people I live with are wonderful. We're planning what improvements to make, and I'm figuring out what to do with the yard, which has great potential. So far the surprise things that have needed to be done haven't surprised me that much -- ~$300 to home depot so far, with about that much on the list again for next time.

In coding news, I got the Mac Mini up into X with DRI on FreeBSD today. There was a kldload bug that had been fixed a while back and I hadn't updated past, and an AGP bug that Linux has a variant of as well. I've got my FreeBSD fix nearly tested to satisfaction, and I think tomorrow I'll be testing the Linux fix.

long time no blog
Huge updates for me. In the last month, we found out our house was going to be put up on the market. Within 3 days, the landlord had accepted an offer, and we had our notice. I had tried to put an offer in, but he accepted another. So, after some fast-paced house-hunting, I found a sweet 4-bedroom place on 53rd and Stark that's newly remodeled (especially the kitchen), has no major issues we've been able to find, a decent back yard with plenty of sun for some gardening, and is still roughly within the neighborhood I wanted to be in. I'm excited, and we're (no, "I'm", I guess) getting keys in less than a week. Incidentally, the offer on this house fell through, and we're all guiltily experiencing some schadenfreude.

Our new housemate is wonderful. She's funny, likes boardgames, is generally clean, and can deal with confrontation in the same way that the rest of this house can't. Plus, she's a prep cook at a nice restaurant, and brings home tasty food. Pretty much your optimal housemate. Even when she was told during the move in process that oh by the way we were probably going to lose the house and have to move in a month, she was cool with that.

Work's been going well. Projects are stacking up, but at least I'm writing open-source driver code like I wanted, and I'm still learning new skills. Recently that was lex and yacc, which I'm ashamed I'd never learned before.

I'm also starting a group to look at converting the FreeBSD repository to git. I've put up a wiki page on the progress, and alexbl and I have been talking about what we should do to come up with a credible proposal. The more I look at git in comparison to hg and svk, the more I'm convinced that it's the right choice not just for xorg but for FreeBSD. Sadly, tonight's conversion experiment failed, and I've got to either fix parsecvs (probably a weekend project, if I had a weekend) or look at the tools that mozilla is using for their conversion. Apparently they're using cvs2svn followed by git-fastimport, taking about 2 hours to convert a repository of comparable size to ports or src.

fix my agp
In my free time, I've been trying to get AGP working in FreeBSD on the G965 I've got sitting next to me. The current patch is here, and it doesn't work yet. Bonus points to whoever figures out what I'm doing wrong.

fd.o git new world order
Today I was working on cleaning up the AGP patches for the 965G, and knew I would want to post my linux-2.6 repository for pulling instead of having to format-patch them for submission again if I could. But fd.o's gitweb and user git repository support was a mess, so I decided to fix it.

Now, user repositories are supposed to live on annarchy (aka people.freedesktop.org) rather than kemper. This means users can create their own repositories and publish them with no admin intervention. New user repos get hooked up to gitweb on a 10-minute cronjob. I also fixed up the gitweb to publish the URLs you would use to interact with repositories (which are incorrect for non-annarchy user repos). Plus, our gitweb is now a branch of upstream, rather than a bare checkout, so we can see what customization we've done.

To migrate your repositories to annarchy, from annarchy run:

cp -Rp /srv/git.freedesktop.org/git/users/username/* ~/

Then, tell me what repos you want removed from kemper, and I'll nuke them from the appropriate places there.

OLS wrapup:

There were definitely some fun talks at this DDC/OLS. Ajax was good fun, as expected, and a nice positive talk about how well we're all doing at fixing long-standing issues is uplifting. idr's GL talk was interesting, but I'm guessing I might have been one of the few really interested by it. The GLSL talk was even more interesting, as GLSL codegen work promises us better performance and features on both new and old hardware. The particular design I was concerned with, but at least some infrastructure is there that we can improve on later. At OLS, airlied's talk was fun, but a bit of an anticlimax as there had been the possibility of a C+D delivered during the talk. The "userspace sucks" talk got a lot of enthusiasm as expected, but some of the criticisms (font reloading) just sounded like a broken local configuration, and the X linux pci issue had already been fixed..

Much of the week I spent hacking on the Intel EXA code. I'd spent too much time on modesetting, and being unable to go hack on EXA had been frustrating. So, I'm almost there -- I think all that should be left at this point is not hanging when compositing with a mask -- I'm sure this is going to be some stupid bug. Then I decided to take a break from that, and work on resurrecting the xorg jhbuild set, for the purpose of the tinderbox and coverity. Things are close to working, with the remaining part being doing something about Mesa.

I discovered that the internet's Ted Haeger blogged about me at GUADEC. GUADEC was excellent fun with much hacking, talking, and relaxing and drinking and swimming in the mediterranean.

OLS was different. Same amount of hacking, on the xorg couches downstairs. Same amount of talking. But this time it's varied between posh dinners with keithp and Bdale, to the "Metal BOF" with airlied, daniels, ajax and co. over at the Dominion pub. They don't even have a door on the bathroom there.

On a sad note, we were disinvited from the Whisky BOF by who we were pretty sure was ajh. We were perfectly reasonable, just hadn't brought more than airlied's flask (not that there was *any* shortage there, with many people rather smashed by the time we arrived and with bottles still untouched). So it was the Metal BOF and the Highlander pub again that night.

Today
Today I made more progress on jhbuild. I was wrong, and xcb was a stumbling block, too. The wiki page is updated for the new bits, and we're a lot closer now. We could probably add "--without-xcb --disable-dri --disable-glx" or something akin to that to the autogenargs and get something that the coverity folks could use. Or probably a little script with a few jhbuilds and a few sets of manual commands, but I want to work on getting it done right (Mesa module in jhbuild, xcb repo renovation if jamey approves), so maybe ajax could take the hacky solution on if he reappears.

I then spent the night debugging the exa branch i915 Composite-with-mask issue. I'm dumping the ring, reading the regs, and things are looking good in what I've read so far. But it still gets hung right at the point that we've dispatched the 3d primitives and go to sync the accelerator.

Now, time for sleep.

xorg-modular-exp
I did some more work on the xorg modular ports for FreeBSD today. Bunches of dependencies are fixed up, there's a working libGL, and some server updates. At this point a lot of the work left is tedious little stuff -- adding comments and descriptions to the ports, adding a couple more missing packages, and fixing up dependencies and a few plists.

The big step remaining is going to be when we test setting X11BASE=${LOCALBASE} in bsd.port.mk. This will likely have significant fallout with ports that assume X11BASE=/usr/X11R6, though in theory ports are already clean for this (Ha! Ha!). And then after that we have to come up with some sort of script for people to run to migrate their existing systems' X11BASE over to LOCALBASE. That may be ugly.

hotpluggy sweetness
I finally managed to get brought a flat panel monitor to play with here at GUADEC. I only got it in exchange for signing up to get hotplug monitors working by Thursday. Only, jrb was a little confused, and thought I already had it done and demanded a demo. So, I decided to demo what I was going to eventually have working: plug in monitor, run xrandr, and have something sensible come up. And, something sensible did come up. The cursor was off, but I automatically chose the right mode, and people were suitably impressed. Impromptu demos working ftw.

I've been cleaning it up, and I'm now switching to full clone mode automatically (cursors work), and I'm not losing track of modes like before. Now I'm working on detecting hot unplug (and saving power in theory as a result, saving memory bandwidth for sure). Keith is rapidly working on the new randr protocol so we can go to mergedfb, and we may end up with the whole thing basically working this week.

I've arrived at GUADEC, and started pushing out patches I wrote on the plane. First to land were new linux_dri ports, so we can run googleearth. Man, someone needs to write an open source version of that program. Then dri-devel for the r300 users. And finally, a cleanup of agp_i810.c that will make adding new PCI IDs cleaner (it was one of two things that have bothered me about agp_i810.c), and slipped the i945 IDs in commented out so that it'll be easy for mux@ and company to test.

Now, people are all excited about the hotpluggy modesetting stuff I'm working on. I need to finish that up. I'll get to nuking the extra copy of libdrm (unfinished patch from the plane) later.

getting ready for GUADEC
I'll be flying out Saturday to head to GUADEC. It's 9+ hours on the plane, but I'm still really looking forward to this -- conferences with desktop people are always fun, and I think we've got some neat WIP stuff to talk about with where we're taking xf86-video-intel's modesetting and what that'll offer for configuration.

In preparation for lots of travel again, I finally got my suspend/resume working. It turned out to be easy -- I had to disable the ioapic (sad because it means no hwpmc, but it sounds like jhb might get to it some day), and I had to set a flag to tell the mouse driver to poke the mouse and see if it wakes up. It sounds like the flag might become the default soon, at least.

I've also made a dummy driver to turn off unused devices in my system. There's a sysctl to do this by default for anything that doesn't get a driver attached, but it causes issues because sometimes other drivers are relying on the functions of another device that doesn't specifically have its own driver attached. For example, I bet setting D3 on the windows dummy second head device of my graphics chip wouldn't give me a result I wanted. So, dummy_powerdown only matches specific device IDs, and I've got a script to dump out the list of devices and their power states. I haven't actually measured any difference in power consumption, though. My kill-a-watt meter is really the wrong thing for this job -- it's on the AC side of things, and doesn't report fractional watts.

So, next step is to find a spare IBM power adapter and hack it up. That and get a bigger battery for next time I travel. I wish I'd remembered to get that two days ago.

modesetting
I've been hard at work since getting back, polishing off issues with the modesetting work I've been doing. Today I got SDVO fixed up so that I can do all the resolutions on my panel, and auto-detect if there's a monitor attached at startup. Now we can do the Mac mini with no options necessary. I'm very happy about that.

Next steps, no specific order after the first:
- Better multihead. I should be able to plug in a monitor and have it just work in clone mode with at most running a single "xrandr" command.
- DVO support. This is used for TV and DVI out on pre-i915, but most importantly, it's what the LVDS sits on on an i830.
- SDVO on other than DFPs.
- TV out on i915. I really want this to happen, but none of the i915s I've got available to me have it.
- look at power consumption

For the SDVO and DVO work, though, I need to figure out what we should be testing on. I've tried to come up with a list of what's out there, which is here, but if anyone knows of other add-in cards for additional outputs on Intel hardware, could they point me at them? Or also, if you've got more information (i.e. what chipsets are involved) on one of the cards listed, I'd love to hear.

And now, it's time for sleep.

I've returned from Chimfunshi (in Zambia) now. It was an amazing trip, and I want to post my journal when I get it typed up, but I'm still getting my stuff sorted out after coming back. I've got over 9000 unread messages, so I'm still catching up here. Oh, and I've got pictures to post, but I need to do some cleanup. There's 700 or so, and you probably don't want to click through 10 pictures of the sunset over the Kafue river.

I also need to work on getting my sleep on a normal pattern. I woke up at 2:30pm today, which is about 11:30pm in Zambia. This is wrong.

So, in two days I'll be flying off to Zambia for 3 weeks. I'll be staying at Chimfunshi with a group of students from Pacific University, including my sister. While there we'll be observing the chimps and helping lead sort of summer camps for local kids and foreign students in Zambia, teaching them about the chimpanzees. I can't wait, and expect that the 3 weeks will fly by.

My internet access will be approximately nothing. Maybe once a week we'll get to fire off emails to our families that we write offline. We're quite priveleged there to have a packet radio link, apparently, considering that Chimfunshi is far from anywhere.

On to open-source, I've been swamped with work recently, and felt like I disappeared for a bit. I did manage to squeeze out a DRM merge to -stable, which has got i915 DRM working at least, and hopefully radeon PCIGART and PCIE GART working (again) as well. I also merged my i915 ARGB cursor fix for AGP. Most intel graphics hardware requires a physical (not GART) address for the cursor. This was easy for old B&W cursors, where you just wired a page and got its physical address. For ARGB cursors, it takes up 4 pages, so it required an actual physically-contiguous allocation. Seems to be working nicely, though. With these bits in place, I've got AIGLX working on FreeBSD on my i915, which is pretty nice. That is, except for the couple of segfaults, which should be easy to debug when I get around to it.

I also played around with gstreamer's ximagesrc yesterday. It's used for screen captures for things like istanbul. There were two solutions implemented, which were both too slow. One was to capture the entire screen each frame. The other was to use xdamage to just copy out any damaged area, each time an area was damaged. Instead I made it so that it copied the union of all the damage that happens between each frame, which fixed performance for nasty things like dragging large opaque windows. It's at #342463 for those interested in taking a look. Hopefully it'll help make things like Istanbul more viable so people can stop using the abomination that is .swf for demos. Unfortunately the Istanbul release is still for 0.8 gstreamer, plus it dies, so I don't have any demos for you myself.

Component Alpha is Easy
Or, making subpixel antialiased fonts go blazing fast.

So, I've previously come out as saying that component alpha rendering was hard (and I wrote the math down wrong even there. Jeez, it's srcv.X = src.X * mask.X, not srcv.X = src.X * mask.A). I really believed it -- we hadn't accelerated it in the what, 5? years that it's been around in X, and my ideas for doing it hadn't been working out. David Reveman supposedly had a way for doing component alpha text (where you've got a solid source), but it required relatively new hardware, and I couldn't see how it would actually work out and didn't find it in the code when I looked. I think he also had a 4-pass system for older hardware. I'd come up with a way to do it on Radeons in 2 passes with a temporary (ugh), and keithp had planned a heinous way to do it in about 2 passes on R200s. But it turns out it's actually easy.

Really, PictOpOver is the only operation we care about. If we support others, cool, but everyone's using Over. The trouble is that component-alpha rendering requires two different sources for blending: one for the source value to the blender, which is the per-channel multiplication of source and mask, and one for the source alpha for multiplying with the destination channels, which is the multiplication of the source channels by the mask alpha. So the equation for Over is:

dst.A = src.A * mask.A + (1 - (src.A * mask.A)) * dst.A
dst.R = src.R * mask.R + (1 - (src.A * mask.R)) * dst.R
dst.G = src.G * mask.G + (1 - (src.A * mask.G)) * dst.G
dst.B = src.B * mask.B + (1 - (src.A * mask.B)) * dst.B

But we can do some simpler operations, right? How about PictOpOutReverse, which has a source factor of 0 and dest factor of (1 - source alpha). We can get the source alpha value (srca.X = src.A * mask.X) out of the texture blenders pretty easily. So we can do a component-alpha OutReverse, which gets us:

dst.A = 0 + (1 - (src.A * mask.A)) * dst.A
dst.R = 0 + (1 - (src.A * mask.R)) * dst.R
dst.G = 0 + (1 - (src.A * mask.G)) * dst.G
dst.B = 0 + (1 - (src.A * mask.B)) * dst.B

OK. And if an op doesn't use the source alpha value for the destination factor, then we can do the channel multiplication in the texture blenders to get the source value, and ignore the source alpha that we wouldn't use. We've supported this in the Radeon driver for a long time. An example would be PictOpAdd, which does:

dst.A = src.A * mask.A + dst.A
dst.R = src.R * mask.R + dst.R
dst.G = src.G * mask.G + dst.G
dst.B = src.B * mask.B + dst.B

Hey, this looks good! If we do a PictOpOutReverse and then a PictOpAdd right after it, we get:

dst.A = src.A * mask.A + ((1 - (src.A * mask.A)) * dst.A)
dst.R = src.R * mask.R + ((1 - (src.A * mask.R)) * dst.R)
dst.G = src.G * mask.G + ((1 - (src.A * mask.G)) * dst.G)
dst.B = src.B * mask.B + ((1 - (src.A * mask.B)) * dst.B)

The best part is that we can do this trick easily (I think it was about 30 lines of code), with no API changes to EXA. My subpixel text on the laptop is now 1/2 speed of non-subpixel text, but 5-6 times faster than before. Sweet.

Making EXA go faster.
Bug #4668 makes my life hard.

The problem is that we don't expect to be able to do component alpha acceleration on most (any) drivers right now. I keep hoping we can make migration Do The Right Thing so that the software fallbacks aren't too bad, but it keeps failing to work (improve one case, degrade another). Currently gnome-terminal with subpixel fonts is the problem. After my last patch improved the situation a bit but left it still ~3 times worse than XAA, I turned on the migration debugging to see what was going on. It appears that gnome-terminal is creating a pixmap, rendering the terminal to it, then copying it to the screen. Then I guess it destroys and repeats for the next update. So you get creation, a few accelerated operations (push it into fb and dirty it), then piles and piles of unaccelerated text (pushing it back out -- huge CPU time hit). My last patch made it push back out faster, which helped, but the simple fact of pushing it out after dirtying in fb is the problem.

Now, I see an easy way to fix this. I just have to wait for some N operations before committing to letting something get dirtied in framebuffer. Only, then, resizing with a compmgr is going to suck because the first thing that happens in resizing is a copy from framebuffer into a fresh pixmap. If I don't let it get dirtied in fb then, it will be very painful.

One crazy idea might be to keep rendering which could be easily (as in, no reads from fb) done by the CPU being done in the system-memory copy as well. This way seems like madness.

Maybe we need to just deal with getting component alpha accelerated somehow. Time to go look at the math again and see what the best way is going to be...

Advertisement