Age | Commit message (Collapse) | Author |
|
|
|
Based on a patch by Will Wiseman.
|
|
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>
|
|
|
|
Disable panel fitting on 855GM, and fix dither setting.
|
|
Using the updated factors even when BT709 conversion isn't available
(non-965) should still give us better color reproduction. Tested on a
945GM, examining the +/-5% of black bars of videotestsrc.
|
|
FD bug #15353. Launchpad bug ID is available for reference.
(cherry picked from commit 24248097988775d62f6c416f2988e74d31c91cd0)
|
|
|
|
|
|
|
|
The 2-bit input_mask was actually an input count -- in0 is always there, and
in1 is optional.
The output flags weren't being reported in the log, so I mistakenly took
controlled_output == RGB0 to mean that the device only reported an RGB0,
while it actually reported RGB0|SVID0|YPRPB0|misc|other. Move SVID0 up
in priority and remove the RGB-is-it-really-TV hack I had just come up with.
Finally, set the input/output mapping at mode set time. We're always
supposed to do this, but haven't had to so far as we've never handled
devices with more than one output.
|
|
Still doesn't light anything up.
|
|
Doesn't include properties for selecting TV formats or picture enhancements,
and totally untested.
|
|
|
|
|
|
|
|
Saving registers means we can run more in parallel.
|
|
Clean up register allocation to never overlap
Always write 4 values for each texture vertex.
|
|
|
|
|
|
|
|
|
|
|
|
Use macros for register names, modularize functions into separate files.
|
|
|
|
sf_mask is the same as sf except that it must compute both src and mask uvw
cooefficients, which are conveniently adjacent in the same registers, and so
need only an extended execution width
|
|
This involves correctly computing u/v locations based on x/y vectors and
line constants computed in new sf program.
Also, use fewer instructions to make this go a bit faster (2X for 500x500
composite).
|
|
|
|
|
|
|
|
|
|
If the legacy bit is set, use both the BLC_PWM_CTL and LBB regs to control the
backlight, rather than just LBB. Looks like more platforms want that than what
the current code does. Note that kernel provided interfaces will always be
used if available, so this shouldn't affect users with /sys/class/backlight
interfaces at all.
Fixes #14721.
|
|
|
|
|
|
|
|
|
|
It's gone, really.
|
|
|
|
o Check for RANDR_GET_CRTC_INTERFACE before defining functions that
are used only if it is defined.
o Declare a variable before code, and rename it from ret to xvmc_status
to better describe it.
o if 0 some static functions not used.
o Don't declare some unused variables.
o Declare as static some functions that are used only in the file defining it.
o Add a default/fallback return True to the Bool function
src/xvmc/intel_batchbuffer.c:intelInitBatchBuffer().
o Ansify src/xvmc/xf86dri.c.
o Add missing prototype to src/xvmc/xf86dri.h and follow pattern of other
headers by adding "extern" before function prototype.
|
|
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.
|
|
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
|
|
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.
|
|
Instead of failing the build, don't even try unless --enable-xvmc was used.
|
|
When overlay switch crtc, it ignores current crtc dpms mode which
might lead to hang.
|
|
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.
|
|
Add i915 headers in Makefile.am
|
|
Reported by Joerg. This does a little more clearn up.
|
|
|
|
They should be listed as lower case, since that's what you'd pass to xrandr.
|
|
Projective transforms require un-normalized texture coordinates and the use
of the texldp instruction. The coordinates are passed as x/y/z/w (the z is
unused, but there isn't a vertext format for just x/y/w).
|