Linux users of Sony Z1 series

[Stuart Shelton <>]

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