| Age | Commit message (Collapse) | Author |
|---|
|
(cherry picked from commit a34a4e3f6420e2b06bbdaa124fe0ccb1bc6a0bd9)
|
|
On #16418, Evgeniy Manachkin <sfstudio@mail.ru> reported that
last asus and eeepc backlight patch is wrong, as acpi_video0 method
will take priority and doesn't work.
(cherry picked from commit 6506ac7aa008436158db4f4196802cab462f3446)
(cherry picked from commit cb4c1fa7499d82beb01566aaf1f323a03ebc1ae4)
|
|
(cherry picked from commit 289790c0467d27e96b537598a6589fc6a36da8b8)
|
|
(cherry picked from commit 4c4ef27779aebf4df90b6233de05be2bb972de4c)
|
|
In full_aspect mode, we try to preserve the aspect ratio by adding
either top & bottom or left & right borders. In the letterbox case (top
& bottom borders) we were miscalculating the top border which led to
programming a bad mode. Fix the calculation and bug #15559.
(cherry picked from commit 5103e5a39a4869a714b8a59da8bf51ecc8c65e4f)
|
|
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)
|
|
i8xx currently only works in FULL mode.
|
|
Disable panel fitting on 855GM, and fix dither setting.
(cherry picked from commit 2b720262e1235f1c9da860ba3e9181f0c377aa5e)
|
|
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.
(cherry picked from commit 1450acd046d47e1739a3ffbd146c73ad2974a935)
|
|
Basic support for panel fitting.
(cherry picked from commit 05cf07071e25f84dec3476a9bed7235ed50cd249)
|
|
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.
(cherry picked from commit c13efdd3d6d3846078766814b57306a7519bce18)
|
|
Using the new interface allows the server to avoid some flicker at startup.
|
|
Tested by Dan Williams.
|
|
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>.
|
|
This should keep the backlight value reported by xrandr --prop & xbacklight
consistent with changes by other software in the system (like the hotkey driver
or kernel backlight driver).
|
|
In some configurations, the LVDS may be off at startup along with the
backlight. So when turning the LVDS on for the first time, we may also need to
set the backlight to a non-zero value. So try to use the saved value if
possible, but if it's zero, make the backlight full brightness when turning on
the LVDS.
Note that this is slightly sub-optimal for configurations where zero is a valid backlight brightness.
Fixes fdo bz #13958.
|
|
|
|
On some platforms, the low bit of BLC_PWM_CTL is wired as a 'max brightness'
flag, rather than a regular part of the backlight duty cycle. So when in the
combo mode, divide the total number of backlight levels available by two
(tossing one bit) and adjust the programming in the set_brightness routine.
Note that platforms with this behavior may need quirks added so that they work
by default.
|
|
We need to save the current backlight value at LVDS init time, as well as when
we change the DPMS setting. Also, since 0 is a valid backlight value, don't
set the backlight value to maximum at startup if the value happens to be zero.
These fixes should make the backlight user experience much more consistent and
hopefully less frustrating.
|
|
Avoids polluting the global namespace with such generic terms.
|
|
This may regress the user experience a bit (fewer backlight levels) on machines
where both the LBB and native registers work, but it's better that it work for
everyone than work extra well for some and not at all for others.
|
|
Open the "actual_brightness" file as read only, since we only read from it.
Also set an initial backlight_duty_cycle at init time so we don't set the
brightness to 0 at startup.
|
|
We need to look at "actual_brightness" rather than "brightness". The former
contains the brightness value the kernel driver has actually set, while the
latter is merely what the user requested.
|
|
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.
|
|
Uncomplicated API transistions for libpciaccess usage:
Legacy xf86 API libpciaccess API
--------------- ----------------
xf86ReadPciBIOS pci_device_read_rom
pciReadWord pci_device_cfg_read_u16
pciWriteByte pci_device_cfg_write_u8
And, more use of the API-independent DEVICE_ID/SUBVENDOR_ID/SUBSYS_ID macros
to pull PCI identification data from the underlying structure.
|
|
- add support for 965GM
- make sure legacy enabled systems don't reduce the range of backlight values we can present to the user
|
|
This one trys to use a flag for possible quirks. It adds a quirk
for my Lenovo T61 TV output, and ports some origin LVDS quirks to it.
|
|
The automatic panel scaling appears to choose bad sampling on some GM965
hardware for 1:1 mapping modes, and there's no real sense in having it on
if we just want 1:1.
|
|
The backlight control in the LVDS controller can either operate in 'normal'
mode or 'legacy' mode. In legacy mode, it uses the PCI config space register
0xf4 which can range from 0 to 0xff. In normal mode, it reads the range and
current value from the BLC_PWM_CTL register.
|
|
|
|
Apparently some BIOSes will program a small mode with large blanking instead of
using the pannel fitter.
|
|
Move clone/crtc config into each output where it's easier to understand (no
need for a switch statement in I830PrepareOutputs. Also, split DVO into
three sub-types (TMDS, LVDS, TVOUT) as those have different cloning
abilities.
|
|
The DVO module interface reflected most of the xf86Output API to the
underlying functions; finish that work given the changes that have since
occurred in the xf86Output API.
Move the LVDS-specific code into the IVCH module and make that work on the
Thinkpad X30 (an i830-based laptop). Panel scaling does not work yet.
|
|
|
|
crestline
|
|
Several places were using byte lengths instead of unit lengths for
properties.
|
|
Remove TV format from mode name, instead use an explicit output property and
split the input resolution from the tv format. Add properties to set the
blank area on all four sides of the image.
|
|
|
|
Conflicts:
src/i810_reg.h
src/i830_display.c
|
|
- Use the existing single/dual-channel state when available, as changing it
doesn't appear to work out.
- Set the power state of the CLKB and B0-B3 pairs according to whether
choose to go dual-channel or not.
- Restore the LVDS register at the appropriate point (before DPLLs are
re-programmed.
|
|
git://proxy.ims.intel.com:9419/git/xorg/driver/xf86-video-intel into crestline
Conflicts:
src/i830_display.c
Change LVDS output and postread like upstream. This might
need to be retested on 965GM LVDS.
|
|
|
|
|
|
New hooks replace explicit invocation of DPMS functions to manage mode
setting sequencing.
|
|
The LVDS register now contains lots of new controls for dual-channel LVDS control
along with dither enabling. The PFIT register has a lot fewer controls as a result.
|
|
|
|
These two sources are placed in higher priority to the BIOS data when
available, since the BIOS data has proven unreliable. The BIOS data is still
read, and warnings printed if it doesn't match what we probe. The BIOS data
remains useful for the situation where we want to turn on LVDS but there is no
EDID available and no current mode programmed (i.e. booting with VGA or TV
connected).
|
|
This adds reasonably driver-independent rotation support to the common
layer. The piece required in the driver is to allocate and redirect the crtc
to a shadow frame buffer. The driver uses Render to perform the actual
rotation operation (which leaves us free to do fun projective transforms at
some point in the future :-).
|
|
|
