I am running 6.8.1 from FC3 (latest devel) on an IBM Thinkpad T42. The key
combination for toggling between LCD and external monitor, fn+f7, stops
functioning as soon as X starts. The keys work fine in character mode (ctrl-alt-f1).
Is X grabbing these keys somehow. I am using acpi to access the keys. All other
fn+fx combinations work fine (with standard ibm-acpi and suspend2 setup).
I need a reliable lcd/external switching since I use the laptop for presentations
the driver is disabling the hotkeys. I'll post a fix shortly.
Created attachment 1461 [details] [review]
enable bios hotkeys
please try this patch. it provides a new option, BIOSHotkeys, that will enable
bios hotkey switching. it's off by default since the driver does not support
ACPI thus there is no way to validate modes on an output switch and the bios
can potentially change things behind the drivers back. however in a basic
single active crtc case it should work fine.
here are some pre-build cvs binaries with the patch applied:
back up your old ones first.
I applied the patch and rebuilt the packages. Modified xorg.conf and put in the
option. xorg.0.log shows the bios keys are enabled.
However, fn+f7 still does not work under X but works in text mode. I am
getting a warning:
(WW) Open APM failed (/dev/apm_bios) (No such file or directory)
I am using ACPI and have APM turned off. Also, Fedora Core 3 is using udev
so perhaps this device needs to be created.
Any Ideas? Thanks.
(In reply to comment #4)
> I applied the patch and rebuilt the packages. Modified xorg.conf and put in the
> option. xorg.0.log shows the bios keys are enabled.
> However, fn+f7 still does not work under X but works in text mode. I am
> getting a warning:
> (WW) Open APM failed (/dev/apm_bios) (No such file or directory)
> I am using ACPI and have APM turned off. Also, Fedora Core 3 is using udev
> so perhaps this device needs to be created.
> Any Ideas? Thanks.
You can ignore that warning. X has support for apm, but for power events, not
buttons. if you are running acpi, X will give you that warning.
please try the new patch.
Created attachment 1477 [details] [review]
please try this one out. new binaries also available at the links above.
Created attachment 1478 [details] [review]
this should work
Argh! Sorry, forgot about about biosscratch 4, 6. please try this one instead.
new binaries available as well.
OK. I am at the office so I can try!
The toggling is still not working under X. There is one difference though
and that is after starting X the first time pressing fn+f7 triggers thinkpad
buttons to display "LCD on, CRT off" or something like this on the screen.
However, at this time they were both on and nothing changed in terms of switching.
Subsequent fn+f7 tries does not produce this message. I do see a flickerring on
the external display everytime I do fn+f7 though.
I have a feeling that fn+f7 is actually working behind X in the textmode screen.
Could this be?
Another thing is that for IBM ThinkPads when there is an external screen
plugged in this becomes the "primary".
One more observation:
When I do fn+f7 after the computer is rebooted, this changes the BIOS
for boot display device to external(VGA) from Thinkpad(LCD). Thus, next
time you boot you only see stuff on the external monitor but nothing on
try again with this part commented out, e.g.,
if (info->MergedFB || pRADEONEnt->HasSecondary)
save->bios_5_scratch = 0x01020201;
I tried that with the same outcome:
The first time I do fn+f7 I get the message from tpb (thinkpad buttons)
that "LCD off, CRT on". Subsequent fn+f7 attempts produce no message.
At the smae time thinkpad BIOS setting for boot display is changed from
"ThinkPad LCD" to "VGA(external)".
Hope this helps!
does fn-f7 work again after you quit X?
Yes..if I do ctrl-alt-f1 and try fn+f7 it toggles perfectly fine. Here is the
comment from ibm-acpi regarding radeon:
"Note that on many models (particularly those using Radeon graphics
chips) the X driver configures the video card in a way which prevents
Fn-F7 from working. This also disables the video output switching
features of this driver, as it uses the same ACPI methods as
Fn-F7. Video switching on the console should still work."
perhaps there's a problem with ibm acpi module. This patch works perfectly on
my radeon laptop.
This patch reverts to the previous driver behavior in the event that you set
BIOSHotkeys to true and it works on my laptop. committed to HEAD.
The problem is ibm-acpi is part of the kernel since 2.6.10 and is the
only acpi module for thinkpads. It is not a matter of who is right or
wrong. There is some conflict between the radeon driver and the ibm-acpi
stuff. fn+f7 works fine with radeon driver on a non-ibm system, not running
ibm-acpi, similarly fn+f7 works fine with ibm-acpi for any other video
driver. I have written to the ibm-acpi author but he does not seem to respond.
(In reply to comment #16)
> The problem is ibm-acpi is part of the kernel since 2.6.10 and is the
> only acpi module for thinkpads. It is not a matter of who is right or
> wrong. There is some conflict between the radeon driver and the ibm-acpi
> stuff. fn+f7 works fine with radeon driver on a non-ibm system, not running
> ibm-acpi, similarly fn+f7 works fine with ibm-acpi for any other video
> driver. I have written to the ibm-acpi author but he does not seem to respond.
> Thank you.
I didn't mean to come across as angry. I'm not trying to argue right or wrong.
With this patch and the BIOSHotkeys options set, X not longer messes with the
bios/acpi. If it still doesn't work, all I can say is that we can rule out X.
In terms of figuring this out, we should probably ask Borislav if the ibm_acpi
module does something weird with regard to the video bios; perhaps it doesn't
even try switching outputs when X is running, I just don't know. FWIW, my
laptop is a thinkpad x24, I've just never had the time to try ibm_acpi.
(In reply to comment #17)
> With this patch and the BIOSHotkeys options set, X not longer messes with the
> bios/acpi. If it still doesn't work, all I can say is that we can rule out X.
> In terms of figuring this out, we should probably ask Borislav if the ibm_acpi
> module does something weird with regard to the video bios;
It's possible. It basically calls ACPI methods used by the code which handles
Fn-F7 and exposes that functionality through a different interface. It's
possible that it's not using some of the low-level methods correctly.
Sammy, can you please try the following: rename or delete the ibm_acpi module
(make sure it doesn't get loaded), reboot, start X with the latest driver and
try Fn-F7. Does it work? If yes, then I can work with you to get it to work with
ibm-acpi (as well as the software switching).
I will test this as soon as I get home this afternoon.
Unfortunately this did not work. I removed ibm-acpi module, rebooted, the
BiosHotkey option was enabled for X11 and shows up in the log file. No
Furthermore, I also tried doing
tail -f /var/log/acpid
and then hit fn+f7 key...no response. Peculiar thing is that I tried it in the
text mode as well and did not see anything despite the fact that video was
What I observed is that when I do fn+f7 the BIOS setting in the computer's
bios does change from "ThinkPad LCD" to "external VGA" but only once i.e. it
does not go back if I hit it again. I can go into bios at startup and
revert it. Is something funny going on?
*** Bug 1230 has been marked as a duplicate of this bug. ***
The patch works with my IBM ThinkPad X31.
Could you tell me what you are running on X31. Kernel, acpi module, tpb etc.
Are you using xorg-x11 or XFree86?
Kernel 2.6.11-rc1, ACPICA 20041210, ibm-acpi-0.10, tpb-0.6.3, xorg-x11-6.8.0 +
Gentoo patch set (-r4).
I pretty much have the same software. I guess this is not too much of a
surprise since the compatibility table shows X31 working for just about
everything. The difference must be in bios/hardware. Did you do anything
special to get fn+f7 work?
I have this problem with my Thinkpad X30 which uses an i830M
video chip, not a radeon.
fn+f7 worked fine with xorg-x11-6.7.0 but stopped working with 6.8.0.
This is not a kernel issue since I first noticed the problem
running 2.4.26. Moving to 2.6.10 has not made it better or worse.
BTW, I am using gentoo and I am running apm, not acpi. I am
not using tpb.
(In reply to comment #26)
> I have this problem with my Thinkpad X30 which uses an i830M
> video chip, not a radeon.
> fn+f7 worked fine with xorg-x11-6.7.0 but stopped working with 6.8.0.
> This is not a kernel issue since I first noticed the problem
> running 2.4.26. Moving to 2.6.10 has not made it better or worse.
> BTW, I am using gentoo and I am running apm, not acpi. I am
> not using tpb.
The xorg i810 driver may have also done something similar (i.e., disabled bios
output handling in the video bios). I don't know enough about the i810 driver
to comment much more than that.
Could someone explain to me the difference betweek the text mode (ctrl-alt-f1)
and graphics mode. I am trying to understand what it means to that fn+f7 work
in text mode and not in graphics mode. Does this mean X/driver is not letting
acpi event for fn+f7?
(In reply to comment #28)
> Could someone explain to me the difference betweek the text mode
> and graphics mode. I am trying to understand what it means to that fn+f7
> in text mode and not in graphics mode. Does this mean X/driver is not
> acpi event for fn+f7?
Not quite. See:
------- Additional Comment #8 From Sammy Umar 2004-12-06 05:54 [reply] -------
> Subsequent fn+f7 tries does not produce this message. I do see a flickerring
> the external display everytime I do fn+f7 though.
I also observe this with my Thinkpad X30/i830M/APM: the output is momentarily
switched (LCD off, external output on) but a fraction of a second later is
On my ati rage (thinkpad A21e), I also see this problem using various gentoo
releases of 6.8.0 with acpi -- never tried with apm.
My partner has a A20m with same video card (I think -- mach64 anyway) and using
an older XFree release from before the fork where the fn-f7 key works correctly
-- never tried acpi on that machine however.
On the a21e I've just been using:
Option "crt_display" "True"
Option "panel_display" "True"
in xorg.conf to keep the crt on all the time (maybe this wastes some battery?)
as its inconvenient to have to restart X to give a presentation.
Same problem on an IBM T30 (2366-85U). /var/log/Xorg.0.log shows the laptop has
an "ATI Radeon Mobility M7 LW [Radeon Mobility 7500]" graphics card. Tried ACPI
and APM. Tried the thinkpad.ko kernel module and tpctl. Tried different
versions of "ATI Radeon" settings for the video card config in "Display
Settings." None of these made any difference wrt to Fn-F7 and X.
Here's some info that may give someone a few clues. On my IBM T41, with the
text console active, both /proc/acpi/ibm/video and the atitvout program
(http://0pointer.de/lennart/projects/atitvout/) work to switch among video
outputs. Unsurprisingly, neither one works with unpatched Xorg 6.7 radeon
driver. Perhaps interesting, though: with the Xorg 6.7 VESA driver, both
ibm-acpi and atitvout *do* work to switch amongst outputs. (atitvout is better
for me because it can switch to the s-video output on my T41, which ibm-acpi can't.)
A minor thing that confused me briefly is that you can't turn off all the
outputs at once, so echo lcd_disable,crt_enable > /proc/acpi/ibm/video doesn't
work. You have to do it in the other order: echo crt_enable,lcd_disable >
BTW, I'm running Mandrake 10.1 with the 188.8.131.52-24mdk kernel and ibm-acpi-0.11.
Maybe this doesn't help much because the VESA driver pretty much doesn't touch
the hardware directly at all, so it's too different from the radeon driver for
comparisons to be useful. :-(
(In reply to comment #22)
> The patch works with my IBM ThinkPad X31.
The patch works with my IBM ThinkPad X31 only if the xorg-x11 server does not
get started with an external VGA monitor connected. It seems like it switches
off the internal display irrevertibly in that case... that is not nice because I
like to use an external display AND the internal one without having to restart
the X session every now and then...
Another observation: when switching to the console (radeon frame buffer) and
back to the Xorg server, the Fn-F7 "setting" gets lost and, if only the external
VGA monitor was active, both heads get activated, again.
*** Bug 4329 has been marked as a duplicate of this bug. ***
Did anybody else here noticed other weird things with external display:
- sometimes the resolution of external diplay is lower than on laptop's LCD (is
it possible to change it?)
- the video clips played by a video player (totem, mplayer) don't appear on
external display (it shows black or blue area), but everything else it's ok.
comment #34: the "blue box" you're seeing with mplayer, etc is the overlay key
from XV accelleration. Perhaps your video card cannot do the overlay on both
displays simultaneously. "mplayer -vo x11 blah.ogg" would display correctly
because it does not use XV accelleration.
(In reply to comment #34)
> Did anybody else here noticed other weird things with external display:
> - sometimes the resolution of external diplay is lower than on laptop's LCD (is
> it possible to change it?)
If DDC information is not available on the vga port, the second crtc gets set up
with the default 640x480 mode. By default the radeon driver drives each display
with it's own crtc. If you'd rather have one crtc drive both displays, disable
mergedfb (Option "mergedfb" "false")
> - the video clips played by a video player (totem, mplayer) don't appear on
> external display (it shows black or blue area), but everything else it's ok.
radeon only has one overlay and it can only be sourced to one crtc or the other.
You can use the xv attribute xv_crtc (or something like that, I don't remember
the exact name offhand) to switch which head it displays on in clone mode. If
you drive both displays with one crtc, the overlay with show on both outputs.
Let's try and keep future discussion more on topic.
Back on topic here:
I have a IBM T42 (Radeon 9600 (Mobility M10)), running Gentoo using
Xorg-6.8.99-15 and linux kernel 2.6.14rc1. I am experiencing the same problem as
the original poster:
If I am using a external display it only works if I boot the laptop into X and
then plugs it in after X is started - if the laptop was booted with the external
display, then only the external display is avalibel in X - the internal LCD gets
switched off (everything is however dandy in the console).
As before fn+f7 only have any effect in console - I have tried switching off IBM
acpi, using APM and none of it works. My (partial) xorg.conf looks like this:
Option "AGPMode" "4"
Option "EnablePageFlip" "on"
Option "RenderAccel" "on"
# enable PowerPlay features
Option "DynamicClocks" "on"
# use bios hot keys on thinkpad (aka fn+f7)
Option "BIOSHotkeys" "on"
# enable radeon specific xinerama
Option "MergedFB" "true"
Option "CRT2Position" "RightOf"
Option "CRT2Hsync" "50-75"
Option "CRT2VRefresh" "30-82"
Option "MetaModes" "1024x768-1280x1024"
Option "MergedNonRectangular" "true"
I hope that someone in here can guide me the right way so I can supply you with
the right debuging info - this is really a anoying problem (I am however not
sure who is to blame X, IBM Bios or ibm_acpi ?) - it should be noted that if I
use the non-free ati drivers then I do not have this problem (but I have a ton
of other problems - like crappy xinerama support - so this is not a solution).
I am experiencing related problems with startup/BIOS/dual-head which I have submitted as bug # 3015.
The patch works on HP nx6130 with local LCD and an external LCD. But when I
connect a TV with S-Video, hotkey can't switch to TV. It can switch to TV under
console mode, and If I use "vesa" driver, it can switch to TV too.
After enabling BIOSHotkeys in xorg.conf, I can use Fn+F7 in the expected way
both in X and on the console. Without enabling BIOSHotkeys, things only work
on the console, Fn+F7 produces nothing.
If I plug in a monitor while X is running I have to hit Fn+F7 twice (to enable
both LCD and CRT output), while if I restart X with the CRT plugged in, the
output gets switched on automatically -- minor detail, but I thought it would
be worth mentioning. I believe it has to do with the "auto" setting in
Thinkpad T40 (ibm-acpi enabled, tpb not used, ACPI 20050902, custom 2.6.14
Radeon 7500 Mobility
Xorg 6.9 RC2 + cvs
I can't get Fn+F7 to switch monitor at all, not even console.
What is needed to get it to work on the console?
Is it handled by ibm_acpi module?
Do you have a special acpid script to handle Fn+F7 ?
I use Ubuntu Breezy. ibm_acpi v.0.12a.
Please try the current ati 1-0-0 branch of the ati driver. It has recently got
som e treatment on this issue.
Ping to the bug submitter!
Is there any indication that there's still an issue in the radeon driver that
specifically prevents Fn+Fx from working? If not, please close this bug and
follow up to other ones about the other issues or file new ones about them.
Still not working on Fedora Core 6
Created attachment 7906 [details]
Option "BIOSHotkeys" "on"
to the device section of /etc/X11/xorg.conf on my T43p Fedora Core 6 system
enables Fn-F7 functionality. I am using the default Fedora installed/updated
driver and the defailt xorg.conf (apart from the above change).
Might be worth moving this to the Red Hat Bugzilla to have this option enabled
in the default Fedora install.
Option "BIOSHotkeys" "on"
fixes it for me too.
Please make this be the default in x.org and let users change the conf file only if they want it disabled (would there be a reason to have it disabled?). Note that there are more and more laptops which have this shortcut, it would be good to have it working out of the box.
Also on Fedora X doesn't require a conf file anymore to start, so having this the default makes sense.
Sorry about the phenomenal bug spam, guys. Adding xorg-team@ to the QA contact so bugs don't get lost in future.
this option bas gone away in git master, however, it recommended that you not use fn-f7, etc. to toggle outputs with the current driver because the bios will likely scramble the chip good better to use xrandr with acpi events.
*** Bug 6705 has been marked as a duplicate of this bug. ***
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.