| Age | Commit message (Collapse) | Author |
|---|
|
At this point, the only remaining feature regressions should be the lack of
overlay support (about to land), and the need to update the XVMC code to work
in the presence of KMS.
Acked-by: Keith Packard <keithp@keithp.com> (in principle)
Acked-by: Carl Worth <cworth@cworth.org> (in principle)
|
|
We can update the cursor without hiding and showing it. In fact, doing the
hide/show causes noticable flicker when running in KMS mode.
Signed-off-by: Jesse Barnes <jbarnes@virtuousgeek.org>
|
|
There's no reason to clip cursor positions to an artificial limit; the
hardware cursor limits always mirror the hardware display limits.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
CVS keywords, comments about how the source was once reformatted,
and the ad-hoc changelog comment in in i830_driver.c
|
|
|
|
Several uses are actually left, which are determined by the X Server
interfaces we're implementing.
|
|
|
|
Failure to do so gets you a lot of pretty colors.
|
|
While we're just doing a memcpy, it's nice for the two argument types to
match.
|
|
Now, we allocate one single block of memory for cursors, and either succeed or
fail once, rather than trying to support partial fallback modes that generally
resulted in pain due to being untested. In particular, this fixes cursors on
FreeBSD, which only allowed one large physically-contiguous allocation.
|
|
This eliminates all of the cursor rotation code and other cursor management
infrastructure, leaving a fairly simple hardware layer in its place.
|
|
|
|
The previous allocator worked in multiple passes, with (at least) one of
setting up allocations, another to attempt to adjust those for tiling, and
then a pass to set up the offsets and fix them in memory.
The new allocator is simpler, allocating memory immediately if possible,
setting up tiling up front, and choosing offsets immediately. AGP memory
is only allocated to back actual memory used, saving some memory that would
have been allocated for padding previous. It will also allow dynamic freeing
and reallocation of memory, which will be useful for framebuffer resizing.
|
|
|
|
When converting from global cursor to per-crtc cursor, the ARGB cursor data
was accidentally painted to the wrong location, overwriting some critical
data and causing the hardware to lock up. (along with generating a garbage
cursor image from uninitialized data).
|
|
|
|
Also, add bind/unbind of the shadow rotate buffers, which was missed in a
previous commit.
|
|
The remaining issue is having a cursor image per CRTC so that the cursors can
be rotated on the independently rotated CRTCs.
|
|
Yes, there are lots of bits tied together here, and we should split this
patch apart.
Move I830 mode setting to xf86 mode setting.
Make mode setting function also set the base address. This should fix
problems where the base gets set incorrectly at times.
Add driver-independent rotation support, requires driver-specific hooks for
shadow pixmap allocation, otherwise it uses Render for painting.
|
|
This makes the CRTCs now always run in gamma-enabled mode, rather than having
flaky logic for switching modes. Also, it should clear up issues with the LUTs
being uninitialized when outputs are first brought up.
|
|
Pull xf86CrtcConfig out of the driver private structure and allocate a
ScrnInfo private index for it. Also, make the arrays of outputs and crtcs
dynamic instead of fixed.
|
|
Place crtc/output in separate structure at head
of driver private structure. Use this from the config code
to make it driver-independent. Still lots of effectively driver
independent code that continues to use driver dependent stuff,
but that will change.
|
|
Outputs and Crtcs are now split between 'generic'
and 'driver specific' pieces in the hope that more code
will be able to migrate to the xf86-generic layer.
Right now, the code remains tangled together, significant
work remains to tease the pieces apart. First the code
needs to be made to actually work as-is though.
|
|
Conflicts in PipeSetMode were resolved to use the keithp changes
that pushed more modesetting stuff into the per-pipe function.
Switched availablePipes to num_pipes.
Used modesetting default output configuration.
|
|
|
|
(cherry picked from e4bcec796e80e9fd66ab0c36394f5946915531f1 commit)
|
|
|
|
|
|
I830 contained six parallel arrays for pipe-specific data; these
have been moved to a I830PipeRec structure instead.
I830 also contained several unused members:
unsigned int bios_version;
Bool newPipeSwitch;
Bool fakeSwitch;
int fixedPipe;
These have been removed, along with the code that set them.
|
|
|
|
This reverts most of the mergedfb code. This will instead be done in device-
independent RandR code.
Conflicts:
src/Makefile.am
src/i810_driver.c
src/i810_reg.h
src/i830.h
src/i830_cursor.c
src/i830_driver.c
src/i830_modes.c
src/i830_video.c
|
|
Mixing random cursors and pipes didn't work very well. I'm left wondering
whether the palette stuff will work on pre-9xx series hardware though; it is
special cased everwhere else.
|
|
This is not entirely what I'd like to see, but it's at least functional.
Limitations:
Can't disable/enable crtcs
Can't move outputs on/off crtcs
But, it does handle monitor hot-plug, detecting changes in VGA and SDVO
status on-the fly. Which makes for good demo material.
|
|
|
|
Conflicts:
src/i830_cursor.c
src/i830_driver.c
|
|
|
|
Conflicts:
src/Makefile.am
src/common.h
src/i810_driver.c
src/i810_reg.h
src/i830.h
src/i830_accel.c
src/i830_cursor.c
src/i830_dri.c
src/i830_dri.h
src/i830_driver.c
src/i830_memory.c
src/i830_rotate.c
src/i830_video.c
|
|
|
|
mode data for each independent screen in mergedfb.
Lots of other fixes too.
|
|
additional pseudo-Xinerama support.
|
|
|
|
|
|
patch is based off of diffing from the branchpoint to the supplied code, but
with many chunks containing reversions of commits removed. Won't work yet.
|
|
|
|
|
|
|
|
|
|
|
|
Add Intel 945GM support
Add RandR rotation support (full 3D acceleration, HWcursor & Xvideo rotated too)
Remove shadow framebuffer rotation code
Add a new LinearAlloc option to allow more offscreen memory to be allocated
for XVideo applications. This allows HDTV movies to be played via Xvideo.
|
|
|
