It is possible to install a new testversion of i810_drv.o that can change the  
bios on the fly:  
http://www.fairlite.demon.co.uk/intel.html  
http://www.fairlite.demon.co.uk/i810_drv.o  
md5sum: /tmp/i810_drv.o  
f126fcfd51b821ffa8378f4b0487606e  /tmp/i810_drv.o  
  
This will add the functionality to force a bios mode to the driver.  
Additionally, the following line must be added to the display driver section  
of /etc/X11/xorg.conf:  
  Option "ForceBIOS" "1280x1024=1280x768"  
This adapted version will probably ship in 6.8.3  
Hibernation works with this driver. This is cool, because 855resolution which 
can also be used to solve this problem does not work with hibernation: on 
resume 855resolution would have to be called, but unless it's in initrd, it 
won't be called. If SuSE 10 would work with suspend2, the resume log could 
take care of this. 
  
Of course Sax would need to know about the ForceBIOS functionality if it would 
use this driver.  
  
The ideal solution to this problem would be a kernel that would fix the bios  
on boot.  

On further testing I found that using the ForceBIOS statment is not acceptable  
because it breaks the suspend to ram functionality (echo mem  
> /sys/power/state).  
  
I guess the best option remaining is to patch the kernel or put 855resolution 
in initrd. 
 

Even more research led me to 
http://www.8ung.at/stingray0481/linux/Inspiron510m/ 
which describes that you can 
modify /usr/lib/powersave/scripts/restore_after_suspend_to_disk to reawake the 
X screen at right resolution. 
 
I've tested this somewhat but can't get it to work completely. 
The mentioned page talks about adding the 855resolution command and using 
chvt. In opensuse you don't need to add chvt because it's already in there. 
855resolution is successfully executed upon restart, but the X server still 
crashes and restarts. Small point of light: it restarts in the correct 
resolution. 
 
 
 

The tools introduced here are patching the BIOS within the memory 
area it is copied to while the system is running. We currently don't have 
an official opinion how we should or should not support that. Patching the 
BIOS from SaX2 is somewhat critical I think :-) 
 
I think we will not include that for 10.0 but I will put Andreas to CC 
for further discussions. Thanks for reporting 

I agree with Marcus, we should not patch the BIOS.

Thanks Andreas so I will close this but remind... 

Maybe i wasn't clear. The programs the no flash the BIOS but only modify the     
copy in memory.      
     
From the README of 915resolution:    
It patches only the RAM version of the video bios so the new resolution    
is loose each time you reboot. If you want to set the resolution each    
time you reboot and before to launch X, use your rc.local, local.start ...    
file of your Linux version.   
   
I know it's not a clean solution, but there's nothing else that can be done.   
The VBIOS is simply wrong on many laptops: it does not contain the right   
resolution for it's own LCD screen.   
  
If the policy is against such patching, why is 855resolution included in SuSE  
10? All I'm asking is to use it in boot.local and  
restore_after_suspend_to_disk. 
 

the problem is if we include it to be used at any place automatically 
we have to support that and fix the bugs around this "non-clean" solution 
as you mentioned. Are you able to define the grade of the tools ? Do you 
know what bugs and system wide problems they can produce ? I know there is 
no alternative but wouldn't you agree that the BIOS and Notebook vendors 
should take care a bit more on their own code ? 
 
only installing the program to provide a service to our customers is 
very different from including and calling the code from within our 
processes. Well this is just my opinion if there is a majority who  
screemed for it we will include it ;) 
 
 

No i don't know the grade. All i know is that i've seen nobody reporting 
problems with the tools (915/855resolution) only successes. That doesn't mean 
they're bugfree though. Also I realize that supporting them would require suse 
to know which laptop needs which resolution, because that's the input the 
tools require. I also know that the laptop vendors are to blame here. But as 
usually the bad impression will be on linux/suse if the code doesn't work with 
the laptop. 
 
Of course i respect your point of view. It's also important to have a stable 
distro with a clean setup. 
 
 
 
 

of course I can understand your point and you are right, the customer 
simply want things to work. From a development prospective this support 
needs to be implemented within libsax which is the library knowing all 
the information to call the tool. 
 
In the first place I would like to know how important our PM sees 
this problem and this requires at least a short discussion in my opinion. 
I will talk about that in the next meeting but I'm pretty sure this will not 
go into 10.0 

Ok getting the full resolution to work with suspend-to-{RAM,Disk} is not so 
difficult anymore. I made a writeup: 
 
http://www.opensuse.org/index.php/User:Jvdoever 
Let's graduate to use suspend-to-disk with full resolution. This requires the 
scripts in /usr/share/doc/packages/powersave/contib/ called video_bios_resume 
and video_bios_suspend. The must be copied into /usr/lib/powersave/scipts and 
make executable with "chmod a+x /usr/lib/powersave/scripts/video_bios_*". 
Adapt the 855resolution command in video_bios_resume to match the command 
in /etc/init.d/boot.local. Now we need to adapt the 
file /etc/sysconfig/powersave/events and change the some entries to:  
EVENT_GLOBAL_SUSPEND2DISK="prepare_suspend_to_disk screen_saver 
video_bios_suspend do_suspend_to_disk" 
EVENT_GLOBAL_RESUME+SUSPEND2DISK="video_bios_resume 
restore_after_suspend_to_disk"  
And you know what? It works like a charm! 
=========================== 
 
So basically the info 
from /usr/share/doc/packages/powersave/README.suspend2ram 
is valid for the Dell Latitude X1 too if you change the call to 855resolution 
to fit the LCD. Maybe this can be generalized: if a variable VIDEO_BIOS_INIT 
is defined, it will be called in local.boot and in video_bios_resume. 
 
 
 

Stefan I put you into CC because of the discussion we had yesterday  

Ok. To summarize for Jos, this is wat i intend to do

- create /etc/init.d/boot.patch-broken-intel-video-bios
  (probably with a different name :-)
- create a config file /etc/sysconfig/broken-intel-bios (different name... :-)
  which basically contains:

  PATCH_VIDEO_BIOS="no" # default, set to yes if you want to use it
  PATCH_PARAMETERS="38 1280 800" # the parameters to use

  maybe we need a selection of which tools to use, but i use 855resolution
  without problems on a i915 chipset, i also expect the different utilities
  to converge into one
- add support to powersaved scripts, this is easy once the above points are
  solved.

I'll start with the 855resolution package and add an init script and a config file.

Hi Stefan, 
 
Sound good to me. /etc/init.d will get rather full though, but that's for you 
guys to decide. 
The right powersaved scripts are already in SuSE. You just need to add the 
variables. 
Will you be able to detect the correct resolution at install/boot time? Maybe 
via the LCDs DDC? If this works well, you could always check of the lcd 
resolution matches that of the bios and change it otherwise. 
 
Cheers, 
Jos 
 

no this settings needs to be done by SaX. Stefan and I talked about a clean  
solution yesterday. We can work together here to get that running. I'm  
currently thinking about an enhancement for libsax to adapt the values of  
/etc/sysconfig/broken-intel-bios and restart the service when needed 
 
maybe we want to have that as a checkbox in the GUI, I'm not sure 

Ok, that sounds good too. 
 

Holla, I proudly present support for patching crappy Intel BIOS has 
been implemented :-) Thanks to Stefan who provided the startup script 
 
  /etc/init.d/boot.videobios 
 
this one allows to patch the bios at boot time. In the current version 
it is still needed to set the value: 
 
  VIDEOBIOS_PATCH=yes 
 
manually ! The default is set to "no" 
 
The parameters needed to call the 855resolution tool will be updated by 
libsax automatically. This means SaX/libsax will take care for the value: 
 
  VIDEOBIOS_PATCH="<params>" 
 
every time a user is using SaX to configure X11 the parameters are set 
in case of broken Intel BIOS. libsax will call 855resolution to be able 
to make use of the changes on the fly. 
 
Well you all may know this is currently rather untested and may cause 
problems so if you recognize anything related to that BIOS patching stuff 
please do not hesitate to contact us. 
 
Thanks 

Just out of curiosity: how does the boot script know which entry in the bios   
should be replaced? Does it always replace 3c, i.e. the highest resolution?   
   
I guess Sax could also set the variable VIDEOBIOS_PATCH, couldn't it?  
  
Guess I'll have to test the next RC :-) 
 

the boot script is using the contents of the variable:  
  
   VIDEOBIOS_PARAMETERS  
  
I'm sorry I made a mistake in my last comment referring that variable.  
currently we are using the entry 3c to override. This is because the  
resolution there is in my opinion never used and is not a VESA standard.  
The contents of VIDEOBIOS_PARAMETERS variable could be for example:  
  
   VIDEOBIOS_PARAMETERS="3c 1280 1024"  
  
This value is updated while using SaX. For example you want to set another  
resolution libsax will update the /etc/sysconfig/videobios file as well.  
  
The contents of VIDEOBIOS_PATCH is not set automatically because we don't 
have any experience whether there are serious problems or not. If the 
system is working we can discuss if libsax should set VIDEOBIOS_PATCH  
as well. Let's see how it works  

*** Bug 118705 has been marked as a duplicate of this bug. ***

Hi guys
I reported 118705. I read all the above with interest. All looks good. I agree
about sloppy manufacturers coding but Microsoft have set the precedent here by
accepting and dealing with crappy coding already, so thats now what the punters
expect and the manufacturers know they can get away with it!

Anyway, am I right in my conclousion that this is therefore 'fixed' in the next
RC and subsequent release?

no, it will be easier to handle and thus fixed in the next release, which means
SUSE 10.1. It will not get fixed in 10.0.