| Age | Commit message (Collapse) | Author |
|---|
|
Signed-off-by: Thomas Hilber <sparkie@lowbyte.de>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
- introduced new xorg.conf options for both intel and radeon FRC patches
- FRC (aka sync_fields) switch (default on)
- process priority (default 0)
- FRC debug output (default off)
- intel Xserver now starts even with disconnected monitor
Signed-off-by: Thomas Hilber <sparkie@lowbyte.de>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
- Full functionality of Radeon based original patch now ported
to recent Intel graphics hardware. This includes support
for i945G chipsets as found on EEE PCs and D945GCLF[2] boards.
- Exploits some special features of i945G chipsets like
vertical phase registers and fine tuning of vertical scaling.
This enables us to compensate for interference effects observed
when driving modern digital displays through a SCART interface.
Signed-off-by: Thomas Hilber <sparkie@lowbyte.de>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
This should improve behavior in the presence of VT switching, but also avoids
a crash on X exit from writing the register after unmapping mmio.
|
|
|
|
We want these to always be set when our driver's in control. They are
already appropriately save/restored at leave/entervt.
(cherry picked from commit 8061e5ac27a5f61f940bccc940be922999cc1d3f)
|
|
(cherry picked from commit 7e51384c973a96366b02ea646392c43574674111)
|
|
Also safe check context size to not exceed surface max.
|
|
Update clock gating disable bits to match docs and allocate a power context
memory area so that newer chips can save state and power down the render unit.
(cherry picked from commit 89bb53cc7a853d88fc34a0ca65ae2b6227a8dd24)
|
|
The Intel xorg driver tries mightily to determine the native fixed
panel mode settings for the LVDS output. It does this through various
means, including scanning video BIOS tables, and noticing if the pipe
in question has already been set up by somebody else (and adopting
those timings). This strategy works well for say a laptop where the
LCD panel is an integral part of the machine. But for other
applications where the display is unrelated to the system's BIOS or
other software, then the BIOS will likely have no clue how to
configure the LVDS output. Worse still, the BIOS can simply "get it
wrong", leaving the pipe misconfigured. Unfortunately the Intel
driver can potentially notice this, adopt the same settings, leaving a
messed up display.
All of this complexity normally happens independently, behind the
scenes, from the mode timings that might otherwise be specified by the
user. This driver has a concept of fixed, i.e. "native" mode, and
then user-specified mode. If the corresponding resolutions between
those concepts don't match, then the driver in theory will arrange for
scaling to take place while adhering to the actual native mode of the
panel. Said another way, if the user says 800x600 but the driver
mistakenly (see above) thinks the native mode is 640x480, then 640x480
is the mode set with scaling to an 800x600 frame buffer. If the
driver gets the wrong native mode, then the result is a miserable mess
with no way for the user to override what the driver thinks is right.
This patch provides a means to override the driver. This implements a
new driver option, "LVDSFixedMode" which defaults to true (the normal,
probe-what-I-need behavior). However when set to false, then all the
guessing is skipped and the driver will assume no fixed, i.e. "native"
mode for the display device. Instead with this option set to false,
the driver will directly set the timings specified by the user,
providing an escape hatch for situations where the driver can't
correctly figure out the right mode.
Under most scenarios of course, this option should not be needed. But
in situations where the Intel video BIOS is hopelessly fouled up
related to the LVDS output, this option provides the escape hatch for
the user to get a working display in spite of the BIOS situation.
Signed-off-by: Mike Isely <isely@pobox.com>
(cherry picked from commit 9f324860431ff8199a78d19bbaa74046e1476b89)
|
|
There are lots of good reasons for doing this, one of them is fdo bug #11305.
(cherry picked from commit 33f033cbf346c13a687e469e8879579fcd5bb2fb)
|
|
(cherry picked from commit a7188b1f2dd9a69fa7daefe478d283735226f9f3)
|
|
Dell Latitude D500s seem to have this problem. At lid close/open, the DSPABASE
reg gets reset to 0, so we either need to keep the framebuffer at offset 0 or
make sure we reprogram the CRTCs after the lid opens again. Since we can't
make sure the former is always true (buffer resize, etc.), this patch adds a
quirk to reset the modes at lid open time.
Fixes FDO bug #14890.
(cherry picked from commit a0ced923bb793aa22e6bfbeeec0888d3b42ce176)
|
|
2D pitch limit applys to all chips. Pre-965 chip has
8KB pitch limit for 3D. 965 supports max pitch by current
exa (128KB).
|
|
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>
(cherry picked from commit e031cc02e65acfbafb48136dad414751e04425c5)
|
|
Disable panel fitting on 855GM, and fix dither setting.
(cherry picked from commit 2b720262e1235f1c9da860ba3e9181f0c377aa5e)
|
|
The homogeneous coordinate computation in the core server cannot be used for
many legal matrices as it overflows. Just use floats in the driver; faster
and avoids troubles.
When compositing with bilinear filter, don't push the dst coordinates around
as that makes the output blurry when pixels are aligned.
|
|
|
|
These are needed to deal with projective transforms in the composite
operation.
|
|
|
|
Using the new interface allows the server to avoid some flicker at startup.
|
|
|
|
|
|
This lets us get better sanity asserts, and avoid mysterious braces when you
do two BEGIN_LP_RING()s in a single function. Potential minor performance
loss isn't too exciting, as ring access is about to become a compat path
anyway. This change also removes the requirement for ring emits to be aligned
to dwords.
|
|
I want to hack on i830 for changing it into a compat path for batchbuffer
without having to worry about the i810 stuff getting broken.
|
|
|
|
Several uses are actually left, which are determined by the X Server
interfaces we're implementing.
|
|
Fix printf formatting warnings, wrap a couple of long lines, nuke
unused variables, add missing #include <unistd.h>.
|
|
Conflicts:
man/intel.man
src/i830_driver.c
|
|
Some machines want DVOA, some DVOB. We can use this quirk to differentiate
them until we come up with a better solution. Patch from Hong Liu.
Fixes #13722.
|
|
Just a partial fix for some of the FBC issues people have been seeing. The
other half is to disable FBC if both pipes are running.
|
|
Order hardware status page setup more reasonable after
all memory bound, in case new chipset requires non-stolen
page and that could be bound then.
Also clean up drm irq handler install function, and put
first install in starting stage later than status page setup,
so we won't make device cry for uninitialized status page.
|
|
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 patch complements 88f8b688e2316ae4a1f7485f0010ce90de54783a which
added uint64_t typed variables to avoid unsigned long overflows in
32-bit architectures but didn't include <stdint.h> with the required
definition.
When XF86DRI and _XF86DRI_SERVER_ are defined this header gets
indirectly included through "i830_dri.h", thanks to "i830_common.h"
which masquerades this problem as released in 2.1.0 and that manifests
with :
In file included from i810_driver.c:88:
i830.h:137: error: expected specifier-qualifier-list before 'uint64_t'
i830.h:240: error: expected specifier-qualifier-list before 'uint64_t'
Patch from Carlo Marcelo Arenas Belon <carenas@sajinet.com.pe>
|
|
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.
|
