| Age | Commit message (Collapse) | Author |
|---|
|
Move xvmc source files under XVMC config
|
|
|
|
Avoids polluting the global namespace with such generic terms.
|
|
|
|
Some of the hw state restoration callbacks may want to use the ring for various
things like stopping video playback, so leave the ring enabled until we get
back from RestoreHWState. Also rename the functions so that their purpose is
clearer and remove a couple of redundant lines.
|
|
This slightly reworks my last fbc patch. We don't
support tiled front buffer with XAA now, so also
disable fbc on it. If tiled alloc failed, disable
fbc too.
|
|
|
|
This commit fixes backlight support for several platforms.
Except on recent machines supporting the IGD OpRegion specification,
backlight control is rather platform specific. In some cases, we can
program the native backlight control regsiters directly without any
trouble. On others, we need to use the legacy backlight control
register. On still others, we need a combination of the two. And on
some platforms, none of the above will work, so we go through the
kernel backlight interface, which provides a platform specific driver
for backlight control.
|
|
|
|
|
|
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.
|
|
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.
|
|
This header file doesn't appear to be getting automatically included for
some reason.
|
|
Conflicts:
src/i830_driver.c
|
|
|
|
It may be that the LVDS chips need to be DVOA and GPIOB only on mobility
devices with them, and DVOC/GPIOE on non-mobility like this 845. But until
more examples are found, just make this one device probe.
|
|
|
|
|
|
Conflicts:
src/i830.h
src/i830_driver.c
|
|
Conflicts:
src/i830.h
src/i830_memory.c
|
|
With the libpciaccess change that added these new APIs, use them
for all mapping.
|
|
Using libpciaccess requires a different type for PciInfo (struct pci_device
instead of pciVideoPtr) and it requires knowing which BAR each memory region
needs to be mapped from. Add these definitions to the driver private record
along with the includes necessary to use libpciaccess.
|
|
This requires EXA 2.2 (server 1.3) for rotated performance with EXA, because
the i830_memory.c allocation may not fall within what EXA considers the
offscreen area, so the PixmapIsOffscreen hook is needed.
|
|
This should fix issues with XV being allocated into XAA's tiled pixmap
cache and resulting bad rendering. Its also brings us closer to being able
to shrink the size of the pixmap cache on XAA, which is of limited utility.
|
|
Add a new 'plane' field to the intel_crtc private structure for tracking
planes separate from pipes. This allows pre-965 chips to use plane A
on pipe B, enabling framebuffer compression for builtin LVDS displays.
|
|
Conflicts:
src/i830_dri.c
src/i830_memory.c
|
|
Now that the driver sets these registers, they must be saved and restored.
|
|
Front buffer tiling is now disabled with G965 and XAA. Some of the acceleration
that i830_xaa.c does can't be supported on tiled buffers.
Adds a tiling field to struct i830_memory, and uses it instead of separate
variables for each potential tiled buffer.
|
|
|
|
This should be close to the last set of tiling fixes for 965 chipsets.
Prior to this commit, the 965 composite hook didn't take tiling into
account, nor did 965 textured video, which caused display corruption.
However, there seems to be at least one last bug to squash--on occasion,
a configuration with tiling enabled won't properly display text. This
is likely another tiling related problem with the composite hook.
|
|
|
|
The 915 and earlier appear to respect the fence registers, while only the 965
requires the per-operation tiling setting and pitch shifting. This will also
fix issues with rendering on the 965 involving multiple cliprects, where the
pitch would get divided repeatedly.
This removes the offset < 4096 fallback, which essentially resulted in no
acceleration to tiled buffers, hiding the issues.
|
|
and put wrap function in driver xvmc priv instead of per xv port priv
|
|
- actually enable tiling in DSP(A|B)CNTR if needed
- add logic to EXA routines for tiled case (still needs work)
- enable/disable fbc on DPMS events (meant moving functions higher in file)
- fix fence register pitch programming (use correct pitch instead of kludged value)
|
|
|
|
- add support for 965GM
- make sure legacy enabled systems don't reduce the range of backlight values we can present to the user
|
|
A number of other interfaces of ours don't allow buffer offsets to be updated
after screeninit. This attempts to catalog why for each one, so that they
can be fixed one by one.
This happens to restore the EXA offscreen allocator for now, as a fixed-offset
object.
|
|
This one trys to use a flag for possible quirks. It adds a quirk
for my Lenovo T61 TV output, and ports some origin LVDS quirks to it.
|
|
To do this, we have to deal with buffer offsets being set at EnterVT time
instead of screen init time. We've wanted to move this direction for a long
time, but there are repercussions. The EXA offscreen memory manager has to
be disabled, because it can't be moved. That will be replaced by BO-backed
pixmaps soon. Also unresolved is whether our moving
front/back/depth/texture buffers will break the classic-mode DRI driver.
This code doesn't actually work yet.
|
|
This is a step towards being able to expose buffer objects through the screen
private to DRI clients, instead of having them have to use the fake buffer
object type.
This fails in two ways. First, the kernel memory manager is not currently
suitable for doing the physical allocations we need, so we still use AGP for
those. Additionally, the DRI lock can't be initialized early enough for us, so
these buffer object allocations fail. This will be fixed by improving the
DRM interface.
|
|
2. clean code
|
|
2. implement macroblock_ipicture instruction
3. 16bit INTRA block
|
|
|
|
I probably need to release a libdrm with this interface in it now..
|
|
If the pipe or output have been set to DPMSOff, then load detection will not
work correctly. Also, share the load detection configuration code between
crt and tv outputs.
|
|
The upper bits would have been inappropriately dropped on G33-class hardware,
and on G965-class hardware in a 32-bit environment. The only use of physical
addresses on these should be for FBC, though, and FBC requires addresses
below 4GB. This is unresolved.
|
|
|
|
- change framebuffer option name to "FramebufferCompression"
- add new "Tiling" option (controls all tiling, not just front buffer)
- add debug message to fb compression enable/disable routines
- update man page with new options
|
|
- move FBC register definitions to i830_reg.h
- add fix from Arjan for 965 depth buffer tiling
- add VT switch and clear-at-server-start code for FBC registers
|
|
"true" in your xorg.conf). Should save ~0.5W during typical 2D usage.
|
