[Openchrome-users] regressions from svn 462:500

[Forest Bond]

Hi,

On Wed, Jan 16, 2008 at 12:23:14AM +0100, Benno Schulenberg wrote:
> Forest Bond wrote:
> > BIOS bugs are quite common, I've found.  I'm not ruling out Xorg,
> > I just feel that it is more likely a BIOS bug, but I could be
> > wrong.
> 
> It's just that I don't see how it could be the BIOS as it's not 
> being used when the openchrome driver is running.

I guess I don't know the low-level interactions well enough; is it not possible
that the VGA BIOS is involving itself in the situation, even if it was not
explicitly asked to do so?

In any case, certainly the BIOS plays a role at boot time, and some degree of
initialization may be going on there that could have impact, right?

> > Well, I checked 462 again, and it does work.
> >
> > The problem is that I checked 500 again after that, and it also
> > seems to (mostly) work.
> 
> That's what I hoped for.  :)  Mistakes are human.

Yes, and I seem to be especially human lately.  I'll see what I can do to patch
that up.

> > There is one minor regression from 462:500 that I am sure about. 
> > Previously, with 462, my mouse cursor had a bluish tint to it.  I
> > did 'Option "HWCursor" "false"' and that seemed to fix things. 
> > It no longer fixes things with r500.
> 
> The HWCursor option is gone and does nothing (you can check in your 
> log), as it was redundant.  Use 'Option "SWCursor" "true"' instead.

Ah, got it.  Thanks.

> > With a different cable, the problem is occuring again.  The
> > problem is not specific to this cable.
> 
> Weird.  Maybe wrong impedance cables?

Maybe; the cable might also be going bad.  It did come with a particular
display, though, so it may not be standard (in terms of impedance).  Dunno.

Now, the interesting news:

Using xrandr to set the resolution fixes the problem.

Let me be clear.  X.org's default behavior for modes set in xorg.conf is a
little odd (in my opinion).  Suppose my Display sub-section looks like this:

  SubSection "Display"
    Depth 16
    Modes "800x600" "1280x720"
  EndSubSection

X.org starts up with the correct mode set ("800x600"), but adjusts its virtual
display size to accommodate the largest mode ("1280x720"), which gives the whole
"virtual desktop" effect--moving the cursor off the screen causes the whole
screen to scroll, revealing different parts of the virtual display.  There's no
way to tell X.org "these are the modes I *might* want to use, but start out with
the smallest one" without it creating a too-large virtual display for the
initial configuration.

"Fine", I thought, "I'll use xrandr in the .xinitrc to force it to use the right
mode and virtual size.  Lo and behold, everything works correctly.  It's very
easy for me to trigger the issue again, I just change my Display sub-section to
this:

  SubSection "Display"
    Depth 16
    Modes "800x600"
  EndSubSection

... and remove the call to xrandr from .xinitrc.

Now what do you think about that? :)

-Forest
-- 
Forest Bond
http://www.alittletooquiet.net
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://wiki.openchrome.org/pipermail/openchrome-users/attachments/20080116/8b4b42ff/attachment.bin