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.
driver idles the ringbuffer, stops it, unbinds all memory, then hands
back off.
Now here's the clever bit: just before we call to idle the ringbuffer
(which sleeps waiting for an interrupt) let's TURN OFF THE FUCKING
INTERRUPT. That's a great idea, really, isn't it?
Move the interrupt disable to *after* stop_ring. Theo's T61 VT switches
again. everyone elses' intel stuff worked by magic (or shared
interrupts) before now.
Fixed after discussion with deraadt@, thanks to miod for suggestions.
ok matthieu@
Original commit message from barry scott to upstream:
Author: Barry Scott <barry.scott@onelan.co.uk>
Date: Tue Jun 23 14:14:50 2009 +0100
Fix segv for clipped movie window
When playing a movie that is clipped on its left and right edges the
Xorg server will SEGV sometimes. This is because the intel driver
ignores the clipping info when it copies the planes out of the XV
data. The check for the optimised copy was wrong to ignore the
width required. Which leads to too much data being copied by the
memcpy. It the source buffe happens to end exactly on a page
boundary the server will SEGV.
As we reviewed the code we checked the calculation of src1, src2 and
src3. The patch includes additional comments to make it clear what
the elements of the calculation are.
This bug exists in git head and we also see it in 2.4.1.
Fix 945GM VT switch in UMS
Bug #19578. We should set private intel_crtc state according to
current, as fail to do so pipe A needs active won't be taken
care of. Also make sure pipe swap operation always set during VT
switch.
This also fixes the *other* x40 lid problem (which happens when you suspend,
then you shut the lid in dont'-suspend-on-lid mode.
the reasoning for the PipeA quirk I finally found:
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.
So essentially, without this patch, if you have this quirk and you shut
the lid, you're hosed, but y'know drivers in userland are great. So are
BIOS writers.
requested by deraadt@, who keeps getting this issue when he's on a plane.
software rasterise them THEN put them into buffer objects.
read-modify-write of graphics memory is expensive.
2.5x speed increase under heavy trap rendering measured.
Another upstream backport. ok matthieu@
in the fastpath they're going straight to the glyph cache anyway and
doing so for small glyphs wastes memory since bos must be padded to page
size.
Backport from upstream (to aid gem development). ok matthieu@
mode from userland. This means we can switch of the vblank ioctl when no
3d client is using it. Backported from newer ddxen to make use of the
new libdrm.
ok matthieu@
both the old i810 and the new intel drivers on i386, and let X
autoconfiguration code choose the one that is used based on the chipset.
Tested by landry@ and a few others.
