| Age | Commit message (Collapse) | Author |
|---|
|
Both methods ACPI lid and SWF bit have issues in LVDS detect from
wider testing. Fallback to origin code.
(cherry picked from commit 4f046af760b92c07f59664359453933fb5358e3d)
|
|
|
|
The LVDS config bits in VBT driver feature block is used by vendor
to identify the board implement of integrated LVDS/eDP or SDVO LVDS.
And video bios uses these bits for LVDS enabling or not. So check
these bits for integrated LVDS might eliminate more quirks.
|
|
Debian "unstable" is still stuck with this ancient version.
|
|
The sony_laptop kernel module (since v2.6.23) supports backlight control
via the sysfs interface:
/sys/class/backlight/sony
This patch will enable xf86-video-intel to use this backlight control method
for Sony VAIO Laptops with Intel integrated video.
|
|
http://bugs.freedesktop.org/show_bug.cgi?id=19247
Because latest xorg will check whether the display is continuous frequency through one flag in monitor info structure,
if not it doesn't touch default modes. When laptop failed to fetch edid, We don't set the flag. In i830_lvds.c,
so currently we can not get default modes except only one mode line from bios.
In order to achieve default modes from xserver successfully,I set the flag and other EDID features.
|
|
If the EDID data from the LVDS doesn't indicate support for a wide range of
continuous frequencies, it will not match any of the default modes although
our LVDS scaler logic ignores refresh rates when programming LVDS modes. Fix
this by smashing the compute EDID data to open up the sync rates.
Signed-off-by: Keith Packard <keithp@keithp.com>
|
|
For broken hardware/bios with incorrect ACPI LID state,
there's machine that can not be fixed in ACPI way, customed
DSDT that reprogram _LID method to read EC state. Although
this is ACPI issue, this quirk can be used to work around that.
|
|
|
|
|
|
This one trys to use lid status for LVDS detect,
which works when internal panel is not used as primary
display alone, or there's no internal panel at all.
ACPI button driver's lid state interface is preferred,
and SWF state is also checked if ACPI method failed.
|
|
The origin check for bring back max value for '0'
backlight level is ok for legacy or combo control method
as '0' mostly doesn't act in ideal lowest level. But it
breaks in using kernel control method which should provide
a reasonable backlight range.
This is tested fine on T61 with thinkpad_acpi module.
|
|
Now that 8xx is fixed, we should be able to preserve aspect ratio by
default.
Fixes fdo bz #18033.
|
|
|
|
The regs are undocumented, but on some machines they work fine, so add this
quirk to indicate it.
|
|
xf86SetDesiredModes() already sets lvds to full mode. later when
xf86CrtcScreenInit() initialized randr12, i830_lvds_set_property will
recall xf86CrtcSetMode and set mode to full. This patch is to remove the
duplication. In my test, this can save about 0.2 - 0.4s x startup time.
|
|
|
|
|
|
|
|
Make VBT parsing happen at driver init time rather than in each output init
function, to save time and better separate VBIOS code into i830_bios.[ch]. The
changes end up touching the output files due to field name changes, and allow
us to reorder & simplify our LFP mode detection code.
|
|
Improve the VBIOS feature detection and use it to find whether the platform
supports spread spectrum clocking. Use the specified reference clock, but
disable SSC if multiple heads are active, since it can cause problems in cloned
configurations.
Reviewed by Nanhai Zou.
|
|
|
|
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.
|
|
Noted and tested by Evgeniy Manachkin <sfstudio@mail.ru>
for asus-laptop support, also add eeepc support.
|
|
|
|
|
|
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.
|
|
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>
|
|
i8xx currently only works in FULL mode.
(cherry picked from commit 33ffd781bbca3d0dee8c1b47e7b90be5824b9a4f)
|
|
Disable panel fitting on 855GM, and fix dither setting.
|
|
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.
|
|
|
|
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.
|
|
|
|
Using the new interface allows the server to avoid some flicker at startup.
|
|
Basic support for panel fitting.
|
|
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.
|
