The Intel driver appears to be coded to only work with displays
expecting 18 bit pixels. However I have an application using a LCD
display that expects pixel data in 24 bit format. The difference is
only 2 bits in a single GPU register. This patch implements that
change, controlled by a new driver option, "LVDS24Bit". The default
value is false, which is the previous behavior. When set to true,
then 24 bit panels should work (at least the one I'm testing here
does).
Fd.o bug #15201
Signed-off-by: Mike Isely <isely@pobox.com>
On some platforms, the firmware may read & write GPU registers on lid close,
suspend/resume time or during various SMM events. If one of the graphics pipes
is disabled at that time, the GPU may hang due to the programming dependencies
of the various registers.
This patch adds a quirk to force the driver to keep pipe A enabled if
necessary, through user configuration in xorg.conf or via a platform specific
quirk. Leaving the pipe enabled comes at a power cost however, so the quirk
should only be enabled when strictly necessary.
Fixes https://bugs.freedesktop.org/show_bug.cgi?id=11432.
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 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.
It had been necessary to allow more than a small amount of memory to be
allocated, but now those old small allocations people had configured are
getting in the way.
With the fixes to the 2D frame buffer allocation that allows up to 65536
lines of 2D frame buffer in XAA mode, the old linear allocation hacks are no
longer necessary.
Driver installs as intel_drv.so with symlink to i810_drv.so to ensure
existing configurations continue to work. Updated manual page to reflect
name change and add attributions for recent work.
The cachelines are used for two things: XAA pixmap cache and XV memory.
Only XAA pixmap cache is referred to using an offset pointing at the
beginning of the front buffer in rendering, and XAA only uses the 2d BLT
engine, which actually has a vertical limit of 65536. So, pixmap cache is now
limited to that much vertical.
Additionally, the previous cachelines allocation was too small for our
advertised XV limits, so video at the limits would fail with BadAlloc. Now,
XAA allocates the same approximate amount of offscreen memory as EXA:
3 times the screen size, plus one packed HD video.
Some code are duplicated with the new libdrm.
Once this code has been released with xserver,
it can be removed.
See the man page for new options and backwards
3D driver compatibility.
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
Mike Isely
Jesse Barnes
Zhenyu Wang
Jesse Barnes
Matthieu Herrb
Jesse Barnes
Eric Anholt
Jesse Barnes
Brice Goglin
Keith Packard
Alan Coopersmith
Michel Dänzer
Thomas Hellstrom
Alan Hourihane
A Costa
Eric Anholt