| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
git+ssh://zhen@people.freedesktop.org/~zhen/xf86-video-intel into xvmc
|
|
|
|
|
|
If EXA is compiled into the driver, default to using it for acceleration.
Hopefully we can remove XAA entirely one day.
|
|
When calling the video DPMS off function, make sure we zero out the current
crtc so that it will be properly re-set up next time video is turned on.
Fix from Peter Clifton with changes by Keith Packard.
|
|
The overlay width & height scaling clamp check was reversed. Fix that and
update the comment.
|
|
In the absence of full suspend/resume support in the kernel, we have to
save/restore state in Enter/LeaveVT. For 8xx chips, 3D state may be lost
during suspend/resume, so re-emit the basic setup at EnterVT time.
Patch from Peter Clifton.
|
|
While I'm here, fix the chip description to be LVDS instead of TMDS in i2c
device.
|
|
If the DPLL isn't enabled or is in VGA mode, writing the PIPEnCONF registers
may cause a hang or crash. So ensure the DPLL is in the proper state before
writing them.
Another excellent fix from Peter Clifton.
|
|
|
|
This should allow it to transition to testing. Closes: #449228
|
|
Fix a long standing bug in the framebuffer compression code (thanks to
Pierre Willenbrock!) that prevented FBC from working correctly if the front
buffer was anywhere but fence register 0.
|
|
|
|
|
|
|
|
Still a lot of things to move include batch buffer, lock, context,
surface resource handling, etc.
|
|
|
|
|
|
|
|
|
|
Use values defined by xvmc lib spec
|
|
|
|
Add a VGA AR dumping function so we can debug text mode problems too.
|
|
|
|
|
|
|
|
This shows one of the reasons for the gaps: with the other settings, the VCO
is too low inside the gap. However, it also points out another issue: we
aren't using the high end of the VCO range due to some other limits being hit.
|
|
|
|
While here, move similar nickle scripts under src/scripts/
|
|
|
|
This shouldn't make a difference now, but for upcoming EXA/batch changes it
will be more useful
|
|
|
|
|
|
|
|
Failure to do so led to the memset() at EnterVT being done to an invalid
offset.
|
|
git+ssh://zhen@people.freedesktop.org/~zhen/xf86-video-intel into xvmc
|
|
When restoring the palette, we weren't checking to make sure the
associated pipe was enabled before writing the registers. In some
configurations, this led to a driver crash. Add new routines to handle
palette save/restore and verify that the pipes are on before we touch
the registers (could easily be changed to enable/disable the pipes
around the save/restore as well).
|
|
|
|
This doesn't help with the most common use-while-unbound cases, which are
from the hardware side.
|
|
|
|
|
|
This allows us to allocate tiled buffers in buffer objects. In the process
I removed the fence division that we had for tiled buffers on pre-965. If we
resurrect that code, it should probably be managed by just dividing all the
objects in roughly half and fencing those halves (to reduce the alignment
requirement), instead of using giant fences until we run out of space and then
trying to deal with scarce space on the last (or not) buffer. Halving
our tiled objects would use 6/8 of our fence registers on that hardware.
|
|
|
|
Otherwise, we would use uninitialized offsets in the early setup.
|
|
While this has been a desired feature for some time, to allow for reallocation
of the front buffer, it was made more necessary by the desire to avoid
requiring a NO_MOVE buffer type in TTM because buffer objects may not be left
pinned over VT switch. This is a step towards making those buffers
movable and resizable.
|
|
There are still issues due to the fact that we're allocating
NEED_LIFETIME_FIXED memory as buffer objects, which we refuse to unpin because
we have no way of pinning it back in the same location.
|
|
We can't guarantee the offset will stay the same using the current DRM
interface, but the correct solution is fixing our code to allow these objects
to move. Breaks TTM mode of the DRI driver for now.
|
|
|
