restore something properly after resume which makes the render ring get stuck.
By defaulting to the "blt" acceleration method we avoid the use of this ring
and the machine remains usable after resume.
People who really want full 2D acceleration can still override the acceleration
method in their xorg.conf.
ok jsg@
From Chris Wilson in
7a9bdadd71730adc5266bc6758982abec5917b93
Fixes rendering problems on Broadwell GT3 (Iris 6100/Iris Pro 6200)
Tested by Thomas Weinbrenner on bugs@
Fixes a display bug seenby ajacoutot@, ok jsg@ and kettenis@.
newer X.Org (2.99.917 or master) version cause corruption on older
machines (X40, i965), probably caused by a bug in our kernel,
under investigation by kettenis@.
builds but won't work as the X server stopped supporting XAA multiple
major releases ago. Furthermore it requires the userland AGP interface
that was removed from the kernel with 5.6. These devices should work
fine with the vesa driver.
ok kettenis@
on ivy bridge, mostly based on upstream drm code:
- remove a workaround which was in itself causing issues
- switch the order of disabling fdi rx & tx
- disable DPLL_SEL when disabling the crtc
- add a few extra delays
Most of this concerns the gen5+ crtc disable function, and thanks
to a bunch of testers this is known to still work fine on gen 5/6/7.
ok kettenis@ matthieu@
Apparently previous version was generated with some of my local changes
to use /usr/bin/libtool. This is causiing problems with the XvMC libs
shared libraries versions.
chipsets to the one in recent intel driver from X.Org.
- remove one of the output probe method in i830PreInit(). This method is
calling functions that are normally forbidden in PreInit(). With
xserver 1.13 this causes a fatal error at run time.
Tested by bluhm@, nick@ and shadchin@ back in september.
maximum causing backlight control to be disabled. Limit the backlight
values to the maximum so xbacklight will work.
Backlight control via the brightness buttons won't yet work as
that likely requires opregion/acpi bits.
Tested by jcs@ jasper@ phessler@ naddy@ and Amarendra Godbole
ok phessler@ kettenis@
Problem noticed by by rivo nurges and blambert@ after ivy bridge
support enabled multiple pipes for pch devices.
Fix based on what the upstream drm code does and
tested by rivo nurges, blambert@ and sthen@
ok kettenis@
access not being adjusted for the pch split, one of which prevented
multiple display pipes from working. The third pipe on ivy bridge
remains disabled for now.
ok kettenis@ thanks to everyone who tested
Since recent(ish) changes we can allocate roatated framebuffers with tiling.
This was not taken into account. Fix this for the most part:
1) i830_display_tiled needs to check tiling on rotated buffers too.
2) PipeSetBase needs to not only set offset to 0 for roated shadow buffers, it
also needs to 0 DSPTILEOFF x/y too.
There seems to be a remaining issue with damage or similar causing some latency
on rotated screens, I have not managed to find this yet.
Tested by sereral on tech@ ok matthieu a couple of weeks ago (his mail slipped
though the cracks, hence late commit).
is completely absent, and playing video doesn't work yet. But support for
"normal" 2D stuff is pretty solid and it is really nice to be able to use
my laptop at the panel's native resolution and be able to suspend and resume
the machine.
tested by some
upsteam code.
Backporting keeping UMS changes by me, some bugfixes from kettenis@.
Has been in snapshots for a while, committed on request so we can be
sure what people are running. This is a prerequesite for sandybridge
support but has those chipsets disabled for now until the correct code
has been added.
It is missing a few commits that I have yet to verify (ones that try and
continue if we lock the gpu rendering engine and can't reset it, for
example) taht will be verified and sent out for extra testing soon.
Should contain a bunch of speedups and some correctness improvements
(though rendercheck still gives some errors that I am looking into).
This has been in snaps since the first day of c2k10, any known issues
with just this driver have (to my knowledge) been fixed since. A problem
with macbooks pointed out by otto happens with both this and the in-tree
driver and thus doesn't stop this moving forward.
As well as the 2.12 improvements, this driver also has a backport
(partially aided by the backports in RHEL 5 kindly provided by Dave
Airlie) from the kms code of modesetting support for ironlake (arrandale
and clarkdale: the IGDs build into intel nehalem cpu dies) which has
been tested on a number of chipsets. Note that Display port and eDP
displays have not yet been worked on (and probably won't until I can
find a displayport monitor), but VGA and lvds at least are known to
work, sure beats vesa.
"no objection on my side" matthieu@, prodding (as always) from princess
marco.
changes from later intel versions (after the UMS removal). 95% of this
is the xvmc reworks that makes that code even halfway sane. xvmc is now
enabled by default on 965+.
Tested by many on tech@, thanks!
ok matthieu@
While this feature at best can save 05w idle power, it is very flakey. Disabling
it fixes (or at the least masks) the problem that some 915 and 945 users were
seeing where they ended up with a blank screen (it turns out that no problems
fired because everything was still working, just FBC screwed up and never
actually scanned out the framebuffer).
As some examples for reliability linux with kms has disabled fbc on these
chipsets due to some unreliability issues (especially over suspend). and the
window driver apparently also does not used it.
Tested by kettenis@, Tom Murphy, edd@ and myself.
ok matthieu@
These files were missing from the last commit. (due to shuffling the cvs
diff between old driver and new one was 155246 lines, so two files isn't
that bad...)
2.9.1 is the last version of the intel DDX that supports UMS (User
modesetting), with 2.10 onwards being purely KMS only. As such, this
driver contains backports of almost every correctness or performance
related fix to the rendering layer in later intel drivers. This driver
*REQUIRES* a GEM enabled kernel. it claims to support non-gem mode but
this is essentially unmaintained and due to the way the abstraciton
works is slow, if it works at all (it often does not). You have been
warned.
tested by many many people on tech over the last few weeks.
