some comments inline, I've removed anything I agree with and have fixed up patches
> (Hrm, would also be nice if this patch created provider objects for the > screens so that we could test the protocol support here) the ddx has to create them at CreateScreenResources time, just like crtc/outputs, the startup ordering demands it :) > >> dix/pixmap: track dirty pixmaps in server. (v3) > > There are bunch of spurious whitespace fixes in dix/pixmap.c > > Fails to check DamageCreate return value for NULL > > PixmapSyncDirtyHelper might be made faster by clipping to the > dirty_region instead of iterating over the boxes in it? I've added a comment for now to investigate this later. > > Setting SourceValidate to NULL is going to pick up the software cursor, > I assume this is intentional? A comment might be nice here. Of course, > a cleaner fix would be to just have the cursor code drive a cursor on > the monitor separately; that way, we'd get hw cursors on the 'main' > screen and only have a sw cursor on the output provider. I'll spend some quality time with cursors again, every attempt at doing anything else has hit some deep seated layering issues. > >> randr: hook up output slave to screen resources return > > Calling RRModesForScreen twice is ugly, but it's probably less code than > creating a separate function to compute the needed values. > > It seems like rrGetMultiScreenResources would work fine for screens > without connected output providers. If so, please just replace the old > function instead of copying it. It'll get more testing that way anyways. I'll put this as a TODO, I've got to fix up the primary stuff for multi-gpu first. > >> randr: add output source setup > > Reviewed-by: Keith Packard <[email protected]> > >> xf86: add output source setting callback > > Not sure you need to mess with the RootClip of the current master screen > when disconnecting the output; you'll get a screen flash as a result. > > Otherwise: > > Reviewed-by: Keith Packard <[email protected]> > >> xf86/cursor: fallback to sw cursor if we have slaves present. > > Would be better to draw the cursor on the slave than have it rendered to > the master and copied to the slave? As you say, all providers can draw X > stuff. I've gone back and forward, and mostly there is layering and SIGIO issues all over the place when I played with this seriously, so I wanted to address it again in the future, but for now just do what works best. I'll resend, you can tack in r-b's for the cursor ones if you think doing it later is best. Dave. _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
