Linux users of Sony Z1 series

[Brouard Nicolas <>]

I think that even if the CRT is on (radeontool dac on) and an external
CRT is not plugged in, it will not consume any power because this is the
way that Window is doing. If it is consuming power then you are right
and we need (LCD off, CRT off) but I suspect not.

We need comments from other people and I will not dispute on this topic.
I just need arguments to do differently from Windows.

Cheers,
Nicolas

Le mar 24/08/2004 à 20:00, Stuart Shelton a écrit :
> On Tue, 24 Aug 2004, Brouard Nicolas wrote:
> > I look at version 1.2 of sonyxosd on your site.
> > (http://files.sony-tools.homeunix.net/sony/_versions/sonyxosd-1.2)
> 
> Simply http://files.sony-tools.homeunix.net/sony/sonyxosd.pl is sufficient
> - it's a symlink to the file above.
> 
> > You took into account my remark concerning the switch from the LCD to an
> > external CRT (called vga in your code). But your scrolling sequences
> > iteration concerns 4 states instead of 3 in my case. You added the
> > sequence LCD off and CRT off. I am not sure that it is necessary. Let us
> > number the 4 states:
> >       4    1    2      3
> > LCD off   on   on    off
> > CRT off  off   on     on
> >
> > My preferred sequences are (4) 1 2 3 1 2 3...
> > and yours is 4 1 3 2 4 1 3 2...
> > And with yours, pushing successively twice Fn F7 gives you twice a blank
> > screen (3 and 4) which makes people confusing when plugging a video
> > projector. I just look at the sequences on Windows and they are the same
> > as mine 1 2 3 1 2 3 etc.
> 
> Sorry - a result of coding whilst tired - it's been a long week so far...
> 
> The problem I have is that if no external display is connected, pressing
> F7 in state 1 seems to have no effect (as we change to state 2) - making
> the system seem unresponsive.  This is what I'm trying to mitigate...
> 
> (Windows gets aruond this by flashing the display annoyingly :)
> 
> I suppose I could argue that if you need to transport the machine whilst
> powered on, then disabling *all* outputs might allow the GPU to power
> down, saving battery...
> ... of course, if suspend worked correctly, this'd be redundant.
> 
> You're right that technically an off/off state is unecessary - but it does
> make the action of the F7 key more consistent.  You know that every press
> changes the LCD state, and every other press changes the CRT state.  I
> personally think that the LCD display is the most important aspect here,
> and that hitting F7 should *always* switch the LCD on or off.
> 
> The problem here is that excluding the off/off state can, at best, only
> give a system where the LCD switches on every press, but the CRT is on for
> two presses then off for one.
> 
> I'll try this tonight and see what it feels like - but I can't help but
> think that including the (essentially useless) off/off state is *much*
> nicer from an HCI point of view, where predictability is everything.
> 
> A better solution that I'll also try is to use your/Microsoft's solution,
> but with a text-bar that announces the current state of the outputs -
> meaning that moving from state 1 to state 2 doesn't seem to do nothing if
> no monitor is conencted.
> 
> If anyone wants to provide any feedback (or alternative ideas) here,
> they're welcome.
> 
> > Also, I think that at boot time the radeon is set to state 2 (on, on)
> > wheter a CRT is plugged or not. So I am not sure that your 'control'
> > state is necessary because it is set by default to 'control' and not to
> > 'on'.
> 
> If state is "on", then the CRT is always enabled;
> If state is "off", then the CRT is always disabled;
> If state is "control", then the CRT can be switched with F7;
> otherwise, the CRT is always enabled.
> 
> At startup, radeontool is used to set the chipset's outputs to be
> consistent with the above.
> 
> Does this make sense?
> 
> Cheers,
> 
>       Stuart