Warren in meeting June 15th

[Darryl Bond]

The business with the default resolution is as you say.
My test machine has a monitor that is capable of 1280x1024 but I cannot
get it to work with greater than 800x600 when I let it autoconfigure.
The ltsp-vmclient is also similar.

This is another issue that may be able to be fixed with xrandr.
If xrandr settings were an administrative setting then users would not
be able to get the videocard/monitor into an unrecoverable situation. If
the administrator got it wrong then a reset of the terminal could get
the new settings.

Darryl


RDP wrote:
> Consistency ends where real live begins.
> Autoconfigure is a big step forward to make the X server more
> intelligent and works out of the box in many cases.
> Autodetecting dual screen graphic cards and configuring them
> accordingly, is still not part of this intelligence, I'm afraid.
> My example is another case, that will remain an exception for some time,
> I guess.
> OLPC Clients using the "AMD Geode LX" chipset.
> Autoconfigure defaults to a resolution of 800x600, while I need
> 1280x1024 for the display. For a correct configuration Horizsync,
> VertRefresh as well as the modeline for 1280x1024 have to be defined.
> Moreover a temporarily option is required to switch off fast rendering,
> due to a bug in the geode driver (Option        "EXANoComposite" "yes").
>
> I have no view of what the impact of the inconsistency will be by making
> configure-x.sh optional, but given the above examples, is there a way to
> avoid it,while keeping the other clients autoconfigured?
>
> K12linux production ready:
> I'm running a test setup for 3 weeks now and haven't come across any
> issues that can be related to ltsp or K12 functionality. I did a second
> successful FC9  install on the same machine/different drive 4days ago.
> Installing ltsp is as simple as: yum install -y ltsp*. The rest of the
> configuration could be done by a simple script.
> Today I will do another install on a different hardware. I also need to
> get the sound working on the clients, which i consider a configuration
> issue rather then a ltsp issue.
> So, from my personal experience, I cannot think of any other issues
> apart from the X config one.
> Regards
> Roger
>
>
> Darryl Bond wrote:
>
>> Making a custom xorg.conf for each chipset/resolution in a large
>> environment is painful.
>> I already have 15 or so different xorg.conf for dual screens,
>> maintaining lots more would be a major hassle.
>>
>> I could live with it if the Driver in the Device section did not have to
>> be explicitly set, ie autoprobe the driver like no xorg.conf does.
>> Then I could share the same Xorg.conf for each resolution.
>>
>> Regards
>> Darryl
>>
>>
>>
>>
>> Warren Togami wrote:
>>
>>> Stuff for next meeting:
>>> * lts.conf options that we currently don't support because we rely on X
>>> autoconfiguration instead of configure-x.sh.
>>> * screen resolution (Our X developers suggest that users who need a
>>> resolution other than default to use a custom xorg.conf file.)
>>> * keyboard layout (code exists to fix it in the rhpl library.  We need
>>> to either use it or copy it)
>>>
>>> I might consider making configure-x.sh optional but:
>>> - it might make things confusing because of inconsistent behavior.
>>> - it needs changes to work without Debian stuff.
>>>
>>> * What else do we need to fix to make K12Linux production ready?
>>>
>>> If you have thoughts about this now, please do write your ideas in this
>>> thread.
>>>
>>> Warren Togami
>>> wtogami at redhat.com
>>>
>>>
>>>
>>>

The contents of this electronic message and any attachments are intended only for the addressee and may contain legally privileged, personal, sensitive or confidential information. If you are not the intended addressee, and have received this email, any transmission, distribution, downloading, printing or photocopying of the contents of this message or attachments is strictly prohibited. Any legal privilege or confidentiality attached to this message and attachments is not waived, lost or destroyed by reason of delivery to any person other than intended addressee. If you have received this message and are not the intended addressee you should notify the sender by return email and destroy all copies of the message and any attachments. Unless expressly attributed, the views expressed in this email do not necessarily represent the views of the company.