| Age | Commit message (Collapse) | Author |
|---|
|
- now supports HDMI 1600x1200 50Hz interlaced resolution
- adjustment control now operates at lower speed which is still fairly sufficient
Signed-off-by: Thomas Hilber <sparkie@lowbyte.de>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
Signed-off-by: Thomas Hilber <sparkie@lowbyte.de>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
- new scheduling option added
Signed-off-by: Thomas Hilber <sparkie@lowbyte.de>
Signed-off-by: Paul Menzel <paulepanter@users.sourceforge.net>
|
|
(affects radeon + intel systems)
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.
|
|
The bit set is now reserved -- used to be a workaround for early revisions.
(cherry picked from commit ad459b21b7de4a79552ac155803d5930432fb84b)
|
|
|
|
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 b61cb9283185eb5211e84eb7d8e68beea607c2eb)
|
|
(cherry picked from commit adb4f5a5e826e584ab212d23fc8d474c3e7bb8e8)
|
|
(cherry picked from commit 7e51384c973a96366b02ea646392c43574674111)
|
|
Besides not being #ifdef __linux__ed as requested, some linux kernels break
in exciting new ways when you try to mprotect from PROT_NONE back to
PROT_READ|PROT_WRITE. Yes, there are bugs in the code we're calling in a
bug-exploiting bug workaround.
If you want this workaround for the original bug exposed when moving to
libpciaccess, it's already in libpciaccess.
(cherry picked from commit 65306cdd71dad71e4ca7229764f81a0880dd70bf)
|
|
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)
|
|
Besides our driver having fallen through to the GM965 path for
RENCLK_GATE_D1, the BIOS was turning some of these on. It may be relevant
for previous platforms as well to zero out the fields that should be zero
in the other registers.
(cherry picked from commit 552a1b824db31a234d7c5cb71057ed0e0ce64477)
|
|
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)
|
|
The fix for flushing at blockhandler with no DRI on 965 was broken and would
try to flush the chip even when the driver wasn't in control of the VT.
Hilarity ensued.
(cherry picked from commit 36ec93300926084fb2951d69b001e4c67bc6ff79)
|
|
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)
|
|
This simply moves code from the driver up into the X server; use it where
available.
(cherry picked from commit fff17b9d1b58cb53032d153094826dd306836d59)
|
|
Mmap from /sys/devices/pci* on linux forces the cache-disable and
write-through bits, which turns our write-combining map into an
uncached-map, seriously impacting performance. It turns out that a bug in
mprotect allows us to fix this by disabling access to those pages and then
immediately re-enabling them.
(cherry picked from commit c3fb62df4e60b63295f94c99b3c5de70dbf94e1c)
|
|
pI830 may point to NULL if I830PreInit fails
(cherry picked from commit 0ae283582d21776d3317d5fc1c25751d50d562c7)
|
|
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)
|
|
(cherry picked from commit 7bba2c13310ed5ac22a355a3cc0ec8b7afaa79cf)
|
|
It's gone, really.
(cherry picked from commit b1f358ba97473b792ec2b7ed5170152faebe7262)
|
|
The new chips no longer automatically flush the rendering cache, so if we
don't flush the RC at blockhandler, the last rendering done may not
appear on the screen. This was particularly noticable with a bare Xorg with
some missing root weave, and terminals where the last character wouldn't
appear until the cursor blinked. A flush in the DRI blockhandler path had
hidden this issue for most people.
(cherry picked from commit 8cdbd55f8075cd18b563badde35815665d7d053e)
|
|
unbound."
While I still like the idea, the mprotect calls themselves are failing on
Linux and causing more trouble than they're worth.
This reverts commit a1612b7728d4153499fe86b6713a13c8702cc7d9.
Conflicts:
src/i830_driver.c
src/i830_memory.c
(cherry picked from commit c02ab432dd7058c700c35eecf6215daf5f262c51)
|
|
|
|
Default XvMC to disabled.
|
|
Move some declarations and don't declare an extra variable with the
same name, to fix warnings about mixed declarations and code.
|
|
Using the new interface allows the server to avoid some flicker at startup.
|
|
|
|
|
|
Unbind and bind a DRM BO may change the buffer offset, thus
crtc may reference a wrong rotated memory after a VT switch cycle.
Destroying it here will cause its reallocation when entering VT.
|
|
|
|
Several uses are actually left, which are determined by the X Server
interfaces we're implementing.
|
|
Conflicts:
man/intel.man
src/i830_driver.c
|
|
And directRenderingDisabled already has config check result.
|
|
|
|
|
|
This simplifies the memory allocation code and fixes a number of bugs.
Prior to this change, some flags may have been set after memory
allocation occurred, meaning they had no effect. It should also make
the allocation logic clearer.
|
|
When checking which pipe a given plane was associated with, we weren't properly
masking the pipe selection bits. Fixes #14481 and should allow the driver to
work with vesafb again.
|
|
For i830M stolen mem size mask should always be 0x70.
Use 0xF0 for later chipsets should be ok, so behavior is
identical to kernel agp.
|
|
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.
|
|
Which was missing in our ScreenInit and initial EnterVT.
This not only causes failure in initial rotation with TTM,
as we won't bind in rotate_mem alloc in this case, and hide
another bug that we call randr12 function in I830LoadPalete
before we call xf86RandR12Init.
|
|
which was observed in rotation crash with stack overflow.
|
|
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.
|
|
|
