9:52 p.m.
I've been running my system for the past week without an xorg.conf file
and it seems to work well
I'm pretty sure that from comments made either on this list or
fedora-test that we are moving in a direction where the norm will be
that no xorg.conf file is needed and therefor won't be created.
I'm having discussions with someone about this at the moment and would
appreciate some clarification on where things are head so that this can
be addressed at their end.[1]
[1] The nvidia service from livna tries to
run /usr/sbin/nvidia-config-display which seems to require a xorg.conf
file in place. It appears that either (a) livna will need to work
around the absence of this file by creating one (how?), and eventually
(b) that nvidia will need to rewrite their software to recognize that
the file need not exist.
R.
--
"It's a fine line between denial and faith.
It's much better on my side"
10:05 p.m.
On Wed, 2008-04-30 at 12:52 +1000, Rodd Clarkson wrote:
I've been running my system for the past week without an
xorg.conf file
and it seems to work well
For a lot of cases, yes, it already does.
I'm pretty sure that from comments made either on this list or
fedora-test that we are moving in a direction where the norm will be
that no xorg.conf file is needed and therefor won't be created.
This is a very strong goal for Fedora 10, at least for me. There are a
couple of outstanding things that are going to have to be taken care of:
*) Getting the X keyboard layout set based on /etc/sysconfig/keyboard
*) Need to be able to pass arbitrary options for input devices (eg, all
the stuff needed for wacom config)
*) Profit :-)
And there's some ideas on how to deal with both problems, there just
wasn't time left for Fedora 9.
I'm having discussions with someone about this at the moment and
would
appreciate some clarification on where things are head so that this can
be addressed at their end.[1]
The right answer here is going to involve an fdi file -- but that's also
then going to require fixing the X server to ask hal which driver to use
rather than the way it currently does
Jeremy
10:19 p.m.
*) Profit :-)
That means automagical dual-head just works, a way to choose Xinerama, and
a way to set the "my second head is 1050 lines high and its bottom line is
the one adjacent to the bottom line of the 1200-line first head" magic
knobs, right?
Oh yeah, and to set DontZap before two weeks go by to disseminate a good
quarter of my brain into various volatile bits of the session and then I
type C-something M-DEL too quickly and fly into that particular biannual
homicidal rage.
Some or all of those things seem ideal to actually live in user desktop
configuration hooey of some sort instead of static system-wide X server
setup, so maybe the glorious road leads in that direction?
Thanks,
Roland
10:21 p.m.
On Tue, 2008-04-29 at 20:19 -0700, Roland McGrath wrote:
> *) Profit :-)
That means automagical dual-head just works, a way to choose Xinerama, and
a way to set the "my second head is 1050 lines high and its bottom line is
the one adjacent to the bottom line of the 1200-line first head" magic
knobs, right?
Oh yeah, and to set DontZap before two weeks go by to disseminate a good
quarter of my brain into various volatile bits of the session and then I
type C-something M-DEL too quickly and fly into that particular biannual
homicidal rage.
Some or all of those things seem ideal to actually live in user desktop
configuration hooey of some sort instead of static system-wide X server
setup, so maybe the glorious road leads in that direction?
In fact, yes, yes it does. See the new gnome-display-properties in F9
for some of the bits of user-configured dual-head magic. Thanks to ssp
for doing the hard work there.
Jeremy
11:07 p.m.
On Tue, Apr 29, 2008 at 11:21:36PM -0400, Jeremy Katz wrote:
> Some or all of those things seem ideal to actually live in user
desktop
> configuration hooey of some sort instead of static system-wide X server
> setup, so maybe the glorious road leads in that direction?
In fact, yes, yes it does. See the new gnome-display-properties in F9
for some of the bits of user-configured dual-head magic. Thanks to ssp
for doing the hard work there.
Right now I need xorg.conf for these things on my desktop Radeon X600
and also my i965 laptop chip:
Option "AccelMethod" "EXA"
So XVideo works and Render accel works.
Virtual 3200 1600
So dual-head actually has somewhere to put the second head :-)
Various options for touchpad, so I can tap-to-click and drag.
Oh, and per-user dual-head/Xinerama configuration doesn't seem to work
so well when the window manager or session manager loads before the
dual-head is configured, resulting in all your icons, applications,
and gnome-panels being restored overlapped on a single-head.
But you probably knew about all these problems already...If you'd like
bugs filed, let me know.
11:17 p.m.
On Wed, 2008-04-30 at 00:07 -0400, Chuck Anderson wrote:
On Tue, Apr 29, 2008 at 11:21:36PM -0400, Jeremy Katz wrote:
> > Some or all of those things seem ideal to actually live in user desktop
> > configuration hooey of some sort instead of static system-wide X server
> > setup, so maybe the glorious road leads in that direction?
>
> In fact, yes, yes it does. See the new gnome-display-properties in F9
> for some of the bits of user-configured dual-head magic. Thanks to ssp
> for doing the hard work there.
Right now I need xorg.conf for these things on my desktop Radeon X600
and also my i965 laptop chip:
Option "AccelMethod" "EXA"
So XVideo works and Render accel works.
In F9 you shouldn't need this EXA should default for intel hw now.
Virtual 3200 1600
So dual-head actually has somewhere to put the second head :-)
This is temporary until we get gpu memory management in place so we can
resize the desktops at runtime.
Various options for touchpad, so I can tap-to-click and drag.
These may end going via hal or gconf settings I would assume..
Oh, and per-user dual-head/Xinerama configuration doesn't seem to work
so well when the window manager or session manager loads before the
dual-head is configured, resulting in all your icons, applications,
and gnome-panels being restored overlapped on a single-head.
Sounds like some sort of a race.. I'm sure ssp can figure out how to stop this..
Dave.
11:24 p.m.
On Wed, Apr 30, 2008 at 02:17:46PM +1000, Dave Airlie wrote:
> Option "AccelMethod" "EXA"
>
> So XVideo works and Render accel works.
In F9 you shouldn't need this EXA should default for intel hw now.
Great for intel. What about radeon?
> Virtual 3200 1600
>
> So dual-head actually has somewhere to put the second head :-)
This is temporary until we get gpu memory management in place so we can
resize the desktops at runtime.
That will be cool.
> Various options for touchpad, so I can tap-to-click and drag.
These may end going via hal or gconf settings I would assume..
Makes sense.
> Oh, and per-user dual-head/Xinerama configuration doesn't
seem to work
> so well when the window manager or session manager loads before the
> dual-head is configured, resulting in all your icons, applications,
> and gnome-panels being restored overlapped on a single-head.
Sounds like some sort of a race.. I'm sure ssp can figure out how to stop this..
I haven't tried again in a while--it's kind of disrupting to have to
reconfigure everything. I'll have to create a new account to test
with.
10:31 p.m.
On Tue, Apr 29, 2008 at 9:05 PM, Jeremy Katz <katzj(a)redhat.com> wrote:
On Wed, 2008-04-30 at 12:52 +1000, Rodd Clarkson wrote:
> I'm pretty sure that from comments made either on this list or
> fedora-test that we are moving in a direction where the norm will be
> that no xorg.conf file is needed and therefor won't be created.
This is a very strong goal for Fedora 10, at least for me. There are a
couple of outstanding things that are going to have to be taken care of:
*) Getting the X keyboard layout set based on /etc/sysconfig/keyboard
*) Need to be able to pass arbitrary options for input devices (eg, all
the stuff needed for wacom config)
*) Profit :-)
Please don't forget us folks who run Fedora on rack-mounted servers in
the back room. I've got a single monitor, mouse, and keyboard shared
via a KVM switch between several machines. The odds are high that
those I/O devices cannot be queried for their properties at X startup
time because the KVM switch is set to some other machine.
--
Jerry James
http://loganjerry.googlepages.com/
3:58 a.m.
"Jerry James" <loganjerry(a)gmail.com> wrote:
Please don't forget us folks who run Fedora on rack-mounted
servers in
the back room. I've got a single monitor, mouse, and keyboard shared
via a KVM switch between several machines. The odds are high that
those I/O devices cannot be queried for their properties at X startup
time because the KVM switch is set to some other machine.
+1
I have a KVM switch between my firewall and desktop machines. While
the desktop was booting up I often switched to the console of the
firewall to do something else, thus making more effective use of my
time. With recent versions of Fedora this results in the desktop not
detecting the monitor and getting a stupid default resolution.
Ron
6:11 a.m.
On Wed, Apr 30, 2008 at 09:58:10AM +0100, Ron Yorston wrote:
"Jerry James" <loganjerry(a)gmail.com> wrote:
>Please don't forget us folks who run Fedora on rack-mounted servers in
>the back room. I've got a single monitor, mouse, and keyboard shared
>via a KVM switch between several machines. The odds are high that
>those I/O devices cannot be queried for their properties at X startup
>time because the KVM switch is set to some other machine.
+1
I have a KVM switch between my firewall and desktop machines. While
the desktop was booting up I often switched to the console of the
firewall to do something else, thus making more effective use of my
time. With recent versions of Fedora this results in the desktop not
detecting the monitor and getting a stupid default resolution.
This also happens when the monitor is off, many users here used to
reboot their machine and turn the monitor off before leaving for the
weekend so they were really confused once they turned the monitor
back on to login a few days later.
Kostas
9:12 a.m.
Once upon a time, Ron Yorston <rmy(a)tigress.co.uk> said:
I have a KVM switch between my firewall and desktop machines. While
the desktop was booting up I often switched to the console of the
firewall to do something else, thus making more effective use of my
time. With recent versions of Fedora this results in the desktop not
detecting the monitor and getting a stupid default resolution.
I discovered that in Rawhide (from last week sometime IIRC), the
installer will crash if you use a USB KVM switch and switch away
(because the USB devices go away; I guess the installer can't handle
hot-plug). I have not filed a bug yet because I only hit it once and
didn't have any time to reproduce.
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
9:31 a.m.
On Wed, 2008-04-30 at 09:12 -0500, Chris Adams wrote:
Once upon a time, Ron Yorston <rmy(a)tigress.co.uk> said:
> I have a KVM switch between my firewall and desktop machines. While
> the desktop was booting up I often switched to the console of the
> firewall to do something else, thus making more effective use of my
> time. With recent versions of Fedora this results in the desktop not
> detecting the monitor and getting a stupid default resolution.
I discovered that in Rawhide (from last week sometime IIRC), the
installer will crash if you use a USB KVM switch and switch away
(because the USB devices go away; I guess the installer can't handle
hot-plug). I have not filed a bug yet because I only hit it once and
didn't have any time to reproduce.
It got filed and I'm pretty sure should be fixed in current rawhide
Jeremy
9:43 a.m.
Once upon a time, Jeremy Katz <katzj(a)redhat.com> said:
On Wed, 2008-04-30 at 09:12 -0500, Chris Adams wrote:
> I discovered that in Rawhide (from last week sometime IIRC), the
> installer will crash if you use a USB KVM switch and switch away
> (because the USB devices go away; I guess the installer can't handle
> hot-plug). I have not filed a bug yet because I only hit it once and
> didn't have any time to reproduce.
It got filed and I'm pretty sure should be fixed in current rawhide
Thanks (sorry I didn't get it filed myself). I'll give it a try
tonight and file/re-open if I still see a problem (I need to double
check an error I was getting on the network page also; I just need some
more round tuits).
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
8:44 p.m.
Once upon a time, Chris Adams <cmadams(a)hiwaay.net> said:
Once upon a time, Jeremy Katz <katzj(a)redhat.com> said:
> On Wed, 2008-04-30 at 09:12 -0500, Chris Adams wrote:
> > I discovered that in Rawhide (from last week sometime IIRC), the
> > installer will crash if you use a USB KVM switch and switch away
> > (because the USB devices go away; I guess the installer can't handle
> > hot-plug). I have not filed a bug yet because I only hit it once and
> > didn't have any time to reproduce.
>
> It got filed and I'm pretty sure should be fixed in current rawhide
Thanks (sorry I didn't get it filed myself). I'll give it a try
tonight and file/re-open if I still see a problem
Nope, it still crashes for me. I didn't find the existing bug (probably
looking for the wrong thing), so I went ahead and opened a new one:
https://bugzilla.redhat.com/show_bug.cgi?id=444844
--
Chris Adams <cmadams(a)hiwaay.net>
Systems and Network Administrator - HiWAAY Internet Services
I don't speak for anybody but myself - that's enough trouble.
8:53 a.m.
On Tue, 2008-04-29 at 21:31 -0600, Jerry James wrote:
On Tue, Apr 29, 2008 at 9:05 PM, Jeremy Katz <katzj(a)redhat.com>
wrote:
> This is a very strong goal for Fedora 10, at least for me. There are a
> couple of outstanding things that are going to have to be taken care of:
> *) Getting the X keyboard layout set based on /etc/sysconfig/keyboard
> *) Need to be able to pass arbitrary options for input devices (eg, all
> the stuff needed for wacom config)
> *) Profit :-)
Please don't forget us folks who run Fedora on rack-mounted servers in
the back room. I've got a single monitor, mouse, and keyboard shared
via a KVM switch between several machines. The odds are high that
those I/O devices cannot be queried for their properties at X startup
time because the KVM switch is set to some other machine.
That's fine.
The way input works now is you _always_ have a virtual core pointer and
core keyboard. As we receive device presence events from hal, we load
drivers for each, and attach their event streams to the core devices.
So configuration happens at plug time, not server startup time.
There's a detail here for outputs, which is that we don't always do
sensible things if we try to start X with no monitor attached, and for
some KVMs it's tough to tell the difference between not attached and
merely not active. That's just a bug though.
- ajax
4:06 p.m.
On Wed, Apr 30, 2008 at 09:53:43 -0400,
Adam Jackson <ajackson(a)redhat.com> wrote:
There's a detail here for outputs, which is that we don't always do
sensible things if we try to start X with no monitor attached, and for
some KVMs it's tough to tell the difference between not attached and
merely not active. That's just a bug though.
Or even when the code knows a monitor is attached, but it doesn't do EDID.
11:41 p.m.
On 4/29/08, Jeremy Katz <katzj(a)redhat.com> wrote:
On Wed, 2008-04-30 at 12:52 +1000, Rodd Clarkson wrote:
> I've been running my system for the past week without an xorg.conf file
> and it seems to work well
> I'm pretty sure that from comments made either on this list
or
> fedora-test that we are moving in a direction where the norm will be
> that no xorg.conf file is needed and therefor won't be created.
A big congratulations from me to everyone who has worked on this on how far
things have come. X11 server configuration has always been the worst part
of setting up new Unix boxes and that's very close to being fixed now.
This is a very strong goal for Fedora 10, at least for me. There are
a
couple of outstanding things that are going to have to be taken care of:
*) Getting the X keyboard layout set based on /etc/sysconfig/keyboard
Has loadkeys been fixed to support Super and Hyper modifier keys from
the console? The X11 setup I got from the Fedora 9 preview had everything
basically correct except for the mislabeled big key to the left of the "A" key.
The other issues (a Lenovo T60 is supposed to be able to handle 1400x1050
resolution, but I'm not sure why it doesn't work and getting the fglrx driver to
work) are separate.
*) Need to be able to pass arbitrary options for input devices (eg,
all
the stuff needed for wacom config)
*) Profit :-)
And there's some ideas on how to deal with both problems, there just
wasn't time left for Fedora 9.
> I'm having discussions with someone about this at the moment and would
> appreciate some clarification on where things are head so that this can
> be addressed at their end.[1]
With all the stupid-key rich Microsoft oriented keyboards in use now, it would
be really nice to have one of the Alt keys produce Alt (the other
Meta) and the two
Microsoft Windows keys produce Super and Hyper by default (and have an easy
knob to tune to put the Ctrl key back in the right place).
I need to see how this works with current Japanese input, but I've had
difficulty
locating Open Wnn for installation to test it.
-sb
1:29 a.m.
Le mardi 29 avril 2008 à 21:41 -0700, SL Baur a écrit :
On 4/29/08, Jeremy Katz <katzj(a)redhat.com> wrote:
> > I'm having discussions with someone about this at the
moment and would
> > appreciate some clarification on where things are head so that this can
> > be addressed at their end.[1]
With all the stupid-key rich Microsoft oriented keyboards in use now, it would
be really nice to have one of the Alt keys produce Alt (the other
Meta)
An awful lot of countries already distinguish between the two alts and
use the right one as iso-level-3 modifier. Some even use right-ctrl as
iso-level-5 modifier. So these keys are not available for remapping
except for American users. If you want them remapped on en_US, just send
a patch to the xkeyboard-config authors.
--
Nicolas Mailhot
1:31 a.m.
Le mardi 29 avril 2008 à 23:05 -0400, Jeremy Katz a écrit :
This is a very strong goal for Fedora 10, at least for me. There are
a
couple of outstanding things that are going to have to be taken care of:
*) Getting the X keyboard layout set based on /etc/sysconfig/keyboard
I hope this will be done by making the console use xkb layouts, so we
can drop the console layout name / X layout name mapping (which is
always incomplete and out of date).
--
Nicolas Mailhot
1:54 a.m.
That is some great work. However, will there be a way to tell X to do
something, instead of what it sees best? i.e. perhaps I don't want to run my
monitor at the highest resolution, perhaps I am attaching a projector, but I
do not want it activated now, rather after I organize my presentation ...
etc
Is there a GUI/CLI tool to talk to X
2:02 a.m.
Ahmed Kamal wrote:
That is some great work. However, will there be a way to tell X to do
something, instead of what it sees best? i.e. perhaps I don't want to
run my monitor at the highest resolution, perhaps I am attaching a
projector, but I do not want it activated now, rather after I organize
my presentation ... etc
Is there a GUI/CLI tool to talk to X
Yes. GNOME has gnome-display-properties. KDE has system settings which
is being improved for KDE 4.1 to support additional features.
Rahul
5:46 a.m.
Nicolas Mailhot wrote:
Le mardi 29 avril 2008 à 23:05 -0400, Jeremy Katz a écrit :
> This is a very strong goal for Fedora 10, at least for me. There are a
> couple of outstanding things that are going to have to be taken care of:
> *) Getting the X keyboard layout set based on /etc/sysconfig/keyboard
>
I hope this will be done by making the console use xkb layouts,
Does it mean that we will have to have xkb things installed even on
machines where X is not installed now?
(servers etc.)
~buc
http://www.fedoraproject.org/wiki/DmitryButskoy
8:12 a.m.
On Wed, 2008-04-30 at 14:46 +0400, Dmitry Butskoy wrote:
Nicolas Mailhot wrote:
> Le mardi 29 avril 2008 à 23:05 -0400, Jeremy Katz a écrit :
>
>> This is a very strong goal for Fedora 10, at least for me. There are a
>> couple of outstanding things that are going to have to be taken care of:
>> *) Getting the X keyboard layout set based on /etc/sysconfig/keyboard
>>
>
> I hope this will be done by making the console use xkb layouts,
Does it mean that we will have to have xkb things installed even on
machines where X is not installed now?
(servers etc.)
The layout data, yes. You wouldn't need the xkb tools (you'd need
console ones instead). But the layout data doesn't take any more space
than the kbd layout data does really
Jeremy
8:26 a.m.
Le Mer 30 avril 2008 12:46, Dmitry Butskoy a écrit :
Nicolas Mailhot wrote:
> Le mardi 29 avril 2008 à 23:05 -0400, Jeremy Katz a écrit :
>> *) Getting the X keyboard layout set based on
>> /etc/sysconfig/keyboard
>>
>
> I hope this will be done by making the console use xkb layouts,
Does it mean that we will have to have xkb things installed even on
machines where X is not installed now?
(servers etc.)
That would mean you'd have the xkb layout definitions installed
instead of one set of layout definitions for the console (kbd) and a
different one for X (xkeyboard-config). Both being inconsistent with
each other and hell to maintain.
--
Nicolas Mailhot
12:12 a.m.
Speaking about xorg.conf. It would be nice to discuss about tablet device
support like Wacom model. So far I have to manually edit that file to fully
enable feature of stylus. Maybe talking to upstream would help.
--
Luya Tshimbalanga
Fedora Project contributor
http://www.fedoraproject.org/wiki/LuyaTshimbalanga
2:21 a.m.
On Wed, 2008-04-30 at 01:12 -0400, Luya Tshimbalanga wrote:
Speaking about xorg.conf. It would be nice to discuss about tablet
device
support like Wacom model. So far I have to manually edit that file to fully
enable feature of stylus. Maybe talking to upstream would help.
Yes. My wife has an old serial Wacom. To add to the fun, she now has a
"legacy-free" laptop. I purchased a USB-serial adapter so she could
continue to use it. This means the serial port device is not necessarily
constant, and may not even be there when X starts up. It works just fine
as long as you kept the serial adapter plugged in at all times.
Unplugging it and plugging it back in tends to cause it to show up as a
the next device number up, which of course screws things up real good...
... Is this kind of setup ever going to "just work"? Its a 12x12in
tablet which is worth quite a bit of $$$. We got it for free some years
back from someone who went Mac OSX and thus couldn't use it anymore.
Wacom and Apple insist USB serial adapters can't work and refuse to
support such a set up in OSX. They're full of crap of course... :)
7:58 a.m.
On Wed, 2008-04-30 at 01:12 -0400, Luya Tshimbalanga wrote:
Speaking about xorg.conf. It would be nice to discuss about tablet
device
support like Wacom model. So far I have to manually edit that file to fully
enable feature of stylus. Maybe talking to upstream would help.
I have the start of some work to get this going, at least on the tablet
PCs. Should be able to translate to the stand-alone tablets as well,
though. I just ran out of time to finish it for F9
Jeremy
8:46 a.m.
On Wed, 2008-04-30 at 01:12 -0400, Luya Tshimbalanga wrote:
Speaking about xorg.conf. It would be nice to discuss about tablet
device
support like Wacom model. So far I have to manually edit that file to fully
enable feature of stylus. Maybe talking to upstream would help.
There's two pieces here. One is just getting the driver loaded, which
we do in fact handle. If lshal shows your Wacom device, we'll load the
linuxwacom driver on it automagically.
The downside (and the other piece) is that we do so with absolutely none
of the mandatory options specified, which means the driver refuses to do
anything with the device. Some of this we could fold into the base
option set, but some of it really is user preference and needs to be
exposed in the UI rather than in xorg.conf. The goal is to have
properties on input devices by the next X server release (ie, 1.6),
which will work more or less like RANDR output properties, and will
allow you to configure things like stylus/eraser/cursor/pad on the fly.
- ajax
2:04 p.m.
Adam Jackson a écrit :
On Wed, 2008-04-30 at 01:12 -0400, Luya Tshimbalanga wrote:
> Speaking about xorg.conf. It would be nice to discuss about tablet device
> support like Wacom model. So far I have to manually edit that file to fully
> enable feature of stylus. Maybe talking to upstream would help.
>
There's two pieces here. One is just getting the driver loaded, which
we do in fact handle. If lshal shows your Wacom device, we'll load the
linuxwacom driver on it automagically.
The downside (and the other piece) is that we do so with absolutely none
of the mandatory options specified, which means the driver refuses to do
anything with the device. Some of this we could fold into the base
option set, but some of it really is user preference and needs to be
exposed in the UI rather than in xorg.conf. The goal is to have
properties on input devices by the next X server release (ie, 1.6),
which will work more or less like RANDR output properties, and will
allow you to configure things like stylus/eraser/cursor/pad on the fly.
- ajax
Glad to hear properties on input devices will be easier on next X server
release.
For now, users with Wacom devices will have to set the properties on
xorg.conf until that issue is resolved. I will install Fedora 9 once it
is released.
Luya
1:25 a.m.
Le mercredi 30 avril 2008 à 12:52 +1000, Rodd Clarkson a écrit :
I've been running my system for the past week without an
xorg.conf file
and it seems to work well
It depends on your hardware. For example evdev keyboard autodetection
was disabled in F9. So if your keyboard requires evdev for full key
support, you need to declare it manually in xorg.conf.
--
Nicolas Mailhot
3:13 a.m.
On 2008-04-30, 02:52 GMT, Rodd Clarkson wrote:
I'm pretty sure that from comments made either on this list or
fedora-test that we are moving in a direction where the norm will be
that no xorg.conf file is needed and therefor won't be created.
I'm having discussions with someone about this at the moment and would
appreciate some clarification on where things are head so that this can
be addressed at their end.[1]
[1] The nvidia service from livna tries to
run /usr/sbin/nvidia-config-display which seems to require a xorg.conf
file in place. It appears that either (a) livna will need to work
around the absence of this file by creating one (how?), and eventually
(b) that nvidia will need to rewrite their software to recognize that
the file need not exist.
The whole truth is that we are on the way towards Stateless Linux
(which means here xorg.conf-less X), but we are not there yet. To
be honest, the way is long and the question is whether we will
arrive at Fedora 10 or later. To make my point clear, we consider
since Fedora Core 6 to be a bug, when Xorg doesn't work at all
withtout /etc/X11/xorg.conf, but that doesn't mean that everybody
should have 3D, etc. automagically.
And of course binary-only nvidia drivers are The Pure Evil(TM),
so those won't be supported ever.
--
"It's a fine line between denial and faith.
It's much better on my side"
Which one it is? ;-)
Best,
Matěj
10:29 p.m.
On Wednesday 30 April 2008 01:13:27 am Matej Cepl wrote:
The whole truth is that we are on the way towards Stateless Linux
(which means here xorg.conf-less X), but we are not there yet. To
be honest, the way is long and the question is whether we will
arrive at Fedora 10 or later.
...
Are we really? Upon what do you base that statement? I'd be very
interested in knowing more, because the Stateless Linux mailing list
looks rather inactive. Is there a roadmap? And what's the current
status?
I'd also interested in contributing if I could, because I've found
portions of it to be extremely useful. I daresay critical for
certain next-generation embedded Linux platforms. It would be great
if progress could be made by Fedora 10, and it would be a real shame
if that opportunity were lost. Especially since Microsoft is picking
up steam in this embedded space, from what I've seen.
-dwight-
12:28 a.m.
On Wed, 2008-04-30 at 19:29 -0800, dwight at supercomputer.org wrote:
On Wednesday 30 April 2008 01:13:27 am Matej Cepl wrote:
> The whole truth is that we are on the way towards Stateless Linux
> (which means here xorg.conf-less X), but we are not there yet. To
> be honest, the way is long and the question is whether we will
> arrive at Fedora 10 or later.
> ...
Are we really? Upon what do you base that statement? I'd be very
interested in knowing more, because the Stateless Linux mailing list
looks rather inactive. Is there a roadmap? And what's the current
status?
We're on our way to the Online Desktop, in which the operating system
itself starts to barely matter at all. (Which should draw people to
Linux since its cheap and reliable, right? :)
1:15 a.m.
2008/5/1 Callum Lerwick <seg(a)haxxed.com>:
On Wed, 2008-04-30 at 19:29 -0800, dwight at supercomputer.org
wrote:
> On Wednesday 30 April 2008 01:13:27 am Matej Cepl wrote:
>
> > The whole truth is that we are on the way towards Stateless Linux
> > (which means here xorg.conf-less X), but we are not there yet. To
> > be honest, the way is long and the question is whether we will
> > arrive at Fedora 10 or later.
> > ...
>
> Are we really? Upon what do you base that statement? I'd be very
> interested in knowing more, because the Stateless Linux mailing list
> looks rather inactive. Is there a roadmap? And what's the current
> status?
We're on our way to the Online Desktop, in which the operating system
itself starts to barely matter at all. (Which should draw people to
Linux since its cheap and reliable, right? :)
Do not believe that this is true at all. But ok. All that will mean is
that every one will be using Windows Live, and there will be even less
of a market for Linux... I guess that's all off-topic however.
--
Fedora 7 : sipping some of that moonshine
( www.pembo13.com )
7:56 a.m.
On Wednesday 30 April 2008 10:28:52 pm Callum Lerwick wrote:
On Wed, 2008-04-30 at 19:29 -0800, dwight at supercomputer.org
wrote:
> On Wednesday 30 April 2008 01:13:27 am Matej Cepl wrote:
> > The whole truth is that we are on the way towards Stateless
> > Linux (which means here xorg.conf-less X), but we are not
> > there yet. To be honest, the way is long and the question is
> > whether we will arrive at Fedora 10 or later.
> > ...
>
> Are we really? Upon what do you base that statement? I'd be very
> interested in knowing more, because the Stateless Linux mailing
> list looks rather inactive. Is there a roadmap? And what's the
> current status?
We're on our way to the Online Desktop, in which the operating
system itself starts to barely matter at all. (Which should draw
people to Linux since its cheap and reliable, right? :)
I don't believe it, but your reply doesn't answer my question.
Where's the roadmap, and what's the plan for getting there? And
who's in charge, and who's involved?
-dwight-
12:52 p.m.
On Thu, 2008-05-01 at 04:56 -0800, dwight at supercomputer.org wrote:
I don't believe it, but your reply doesn't answer my
question.
Where's the roadmap, and what's the plan for getting there? And
who's in charge, and who's involved?
Who's involved? Google is currently leading the way, especially in the
"back end":
http://www.google.com/a/help/intl/en/var_0.html
GNOME is working on a front end:
http://live.gnome.org/OnlineDesktop
And Red Hat is integrating it all:
http://mugshot.org/
If you're expecting roadmaps and plans, you're going to be disappointed.
This is new territory, just being discovered. Who's in charge? Whoever
gets there first.
10:12 p.m.
On Thursday 01 May 2008 10:52:35 am Callum Lerwick wrote:
http://www.google.com/a/help/intl/en/var_0.html
GNOME is working on a front end:
http://live.gnome.org/OnlineDesktop
And Red Hat is integrating it all:
http://mugshot.org/
If you're expecting roadmaps and plans, you're going to be
disappointed. This is new territory, just being discovered. Who's
in charge? Whoever gets there first.
I think you're confusing Stateless Linux with Stateless Linux
Desktop. You might want to check out the Fedora Wiki regarding
Stateless Linux, and see what it's actually about. It covers
quite a bit more than just the Desktop.
Google and Gnome are notably absent from the project. Granted, the
Wiki might be out of date, as the Fedora Stateless Linux project
seems to be rather dead, with no mail even being generated on its
mailing list of late.
The key point of interest to me is that that there are a number of
issues which remain in Fedora's current Stateless Linux
implementation even before you get to the Desktop, or any other apps
which are built on top of the Stateless Linux functionality.
Personally, I could care less about the Desktop or Google Apps in
this particular regard. I'm more interested in getting the basic
O.S. issues solved.
If you do it right, you can kill several important birds with one
stone. But it's not there yet.
It also strikes me as being relatively straightforward towards
ironing out these issues (and yes, I'll volunteer to do some of the
work). But I'm not going to spend time on it if someone else is
doing it. Or if my interpretation of what needs to be done isn't in
sync with the general project.
Nor if Stateless Linux (not Stateless Desktop) is dead, and has no
future.
-dwight-
10:41 a.m.
On 2008-05-02, 03:12 GMT, dwight at supercomputer.org wrote:
I think you're confusing Stateless Linux with Stateless Linux
Desktop.
You are confusing Stateless Linux and Online Desktop.
Matěj
11:17 a.m.
On Friday 02 May 2008 08:41:20 am Matej Cepl wrote:
On 2008-05-02, 03:12 GMT, dwight at supercomputer.org wrote:
> I think you're confusing Stateless Linux with Stateless Linux
> Desktop.
You are confusing Stateless Linux and Online Desktop.
Matěj
Not at all. I'm using the term "Stateless Linux" as defined the
Fedora Wiki, and as currently implemented in Fedora. This is a
Fedora list. after all.
-dwight-
10:39 a.m.
On 2008-05-01, 03:29 GMT, dwight at supercomputer.org wrote:
Are we really? Upon what do you base that statement? I'd be
very interested in knowing more, because the Stateless Linux
mailing list looks rather inactive. Is there a roadmap? And
what's the current status?
I used “Stateless Linux” in very open meaning of the word. AFAIK
it is now more state of mind, than a real project.
Matěj
11:20 a.m.
On Friday 02 May 2008 08:39:46 am Matej Cepl wrote:
On 2008-05-01, 03:29 GMT, dwight at supercomputer.org wrote:
> Are we really? Upon what do you base that statement? I'd be
> very interested in knowing more, because the Stateless Linux
> mailing list looks rather inactive. Is there a roadmap? And
> what's the current status?
I used “Stateless Linux” in very open meaning of the word. AFAIK
it is now more state of mind, than a real project.
Matěj
Thanks for clarifying that. From my point of view, I'm talking about
real code, as currently implemented. Hopefully we have that all
cleared up.
-dwight-
3:56 a.m.
On Wed, Apr 30, 2008 at 12:52:20PM +1000, Rodd Clarkson wrote:
I've been running my system for the past week without an
xorg.conf file
and it seems to work well
I'm pretty sure that from comments made either on this list or
fedora-test that we are moving in a direction where the norm will be
that no xorg.conf file is needed and therefor won't be created.
I think it is not good idea. Autoconfiguration is generally better than
manual but in some cases autoconfiguration cannot help you. Examples:
- your xyz driver is broken and you want use vesa temporarily
- you want use some external module (like vnc module)
- you are user who needs fine-grained configuration (autoconfiguration
is good for masses but sometimes people needs more)
Best should be use autoconfiguration as much as possible but preserve
and create minimal xorg.conf.
Adam
--
Adam Tkac, Red Hat, Inc.
4:07 a.m.
On Wed, Apr 30, 2008 at 10:56:48AM +0200, Adam Tkac wrote:
I think it is not good idea. Autoconfiguration is generally better
than
manual but in some cases autoconfiguration cannot help you. Examples:
- your xyz driver is broken and you want use vesa temporarily
- you want use some external module (like vnc module)
- you are user who needs fine-grained configuration (autoconfiguration
is good for masses but sometimes people needs more)
Best should be use autoconfiguration as much as possible but preserve
and create minimal xorg.conf.
I agree on this.
Besides frequent issues with new hardware (and thus having to specify
drivers or turn of acceleration etc.) I use xorg.conf for setting
blank/standby/suspendtime values, for specifying extra input devices
(like touch screens) ans for loading the vnc module (with options).
Having a minimal configuration that works for the masses is better,
IMHO.
--
-- Jos Vos <jos(a)xos.nl>
-- X/OS Experts in Open Systems BV | Phone: +31 20 6938364
-- Amsterdam, The Netherlands | Fax: +31 20 6948204
6:37 a.m.
Adam Tkac <atkac <at> redhat.com> writes:
I think it is not good idea. Autoconfiguration is generally better
than
manual but in some cases autoconfiguration cannot help you. Examples:
- your xyz driver is broken and you want use vesa temporarily
- you want use some external module (like vnc module)
- you are user who needs fine-grained configuration (autoconfiguration
is good for masses but sometimes people needs more)
Best should be use autoconfiguration as much as possible but preserve
and create minimal xorg.conf.
I would like to be re-assured that the issues that Adam raises are
still possible, perhaps via a different config facility, if there were a fully
xorg.conf'less X in future. In particular I most definitely would be very
disadvantaged without the vnc module. Can anyone respond to say how
this module would be loaded when X started if it there is no xorg.conf?
Similarly how would the current touchpad parameter changes to customise
the touchpad be input without an xorg.conf?
I presume that these issues have been thought about even if there is no
complete answer at present? Some idea of what needs to be developed in
order to accommodate these reductions in capability must surely have
been thought through before the decision to develop X to the point of
not having xorg.conf for F10?
8:28 a.m.
On Wed, 2008-04-30 at 10:56 +0200, Adam Tkac wrote:
On Wed, Apr 30, 2008 at 12:52:20PM +1000, Rodd Clarkson wrote:
> I've been running my system for the past week without an xorg.conf file
> and it seems to work well
>
> I'm pretty sure that from comments made either on this list or
> fedora-test that we are moving in a direction where the norm will be
> that no xorg.conf file is needed and therefor won't be created.
I think it is not good idea. Autoconfiguration is generally better than
manual but in some cases autoconfiguration cannot help you. Examples:
- your xyz driver is broken and you want use vesa temporarily
Ultimately, we should be fixing these bugs. Not having a config file to
work around them. But at the same time, the idea is that you can do
things like this at the hal level with fdi files rather than xorg.conf
- you want use some external module (like vnc module)
Not sure what the best answer for these are... I defer to ajax :)
- you are user who needs fine-grained configuration
(autoconfiguration
is good for masses but sometimes people needs more)
But a lot of the configuration is *user* based -- not the system.
Best should be use autoconfiguration as much as possible but
preserve
and create minimal xorg.conf.
How does an empty xorg.conf help anyone? There's nothing saying that if
you _create_ one it won't be followed, but in the general case, one
shouldn't be needed and we shouldn't be writing one out.
Jeremy
9 a.m.
On Wed, 2008-04-30 at 09:28 -0400, Jeremy Katz wrote:
On Wed, 2008-04-30 at 10:56 +0200, Adam Tkac wrote:
> I think it is not good idea. Autoconfiguration is generally better than
> manual but in some cases autoconfiguration cannot help you. Examples:
>
> - your xyz driver is broken and you want use vesa temporarily
Ultimately, we should be fixing these bugs. Not having a config file to
work around them. But at the same time, the idea is that you can do
things like this at the hal level with fdi files rather than xorg.conf
The answer here is that xorg.conf is allowed to be _very_ small. All
the pieces you don't fill in will be filled in from the default
configuration heuristic.
Ideally, though this doesn't work yet, you'd just do:
Section "Device"
Driver "vesa"
EndSection
and the rest would get filled in for you.
> - you want use some external module (like vnc module)
Not sure what the best answer for these are... I defer to ajax :)
You should be able to load the vnc module, while still preserving the
rest of the autoconfig logic, with a config file consisting of just:
Section "Module"
Load "vnc"
EndSection
This _should_ work today. Please let me know if it doesn't!
- ajax
8:41 a.m.
On Thu, 2008-05-01 at 00:22 +0200, Dennis Jacobfeuerborn wrote:
Adam Jackson wrote:
> Ideally, though this doesn't work yet, you'd just do:
>
> Section "Device"
> Driver "vesa"
> EndSection
It doesn't? This is what my xorg.conf looks like:
Section "Device"
Driver "nouveau"
Identifier "Videocard0"
EndSection
That works fine for me.
Nice! I still don't like the magic Videocard0 there, that should get
filled in for you. But that's better than I thought.
- ajax
12:50 p.m.
On 2008/04/30 10:56 (GMT+0200) Adam Tkac apparently typed:
Autoconfiguration is generally better than
manual but in some cases autoconfiguration cannot help you. Examples:
- your xyz driver is broken and you want use vesa temporarily
- you want use some external module (like vnc module)
- you are user who needs fine-grained configuration (autoconfiguration
is good for masses but sometimes people needs more)
- switched multiple displays for single head system
- KVM switch connected to another system
- display's EDID and/or DDC is missing or dysfunctional
--
"Either the constitution controls the judges, or the
judges rewrite the constitution." Judge Robert Bork
Team OS/2 ** Reg. Linux User #211409
Felix Miata *** http://fm.no-ip.com/
1:55 p.m.
On Wed, 2008-04-30 at 10:56 +0200, Adam Tkac wrote:
- your xyz driver is broken and you want use vesa temporarily
Once again, look to Windows. Implement a rescue mode of some sort that
falls back to VESA or even plain VGA if that fails. (Does VESA ever not
work anymore? Do we even support plain VGA anymore? I still remember the
days when cards didn't have VESA in them... :) Automatically trigger it
when X Keeps Crashing, plus some kind of manual trigger for other cases,
possibly triggered by a kernel command line option, which GRUB could
then be modified to provide a friendly user interface for...
- you want use some external module (like vnc module)
Make modules like this dynamically runtime loadable, and possibly
un-loadable. Or hell, just load it all the time, in a disabled state if
it is unwanted. (Though I think doing VNC outside the X server is
probably the Right Thing, but the fact remains vnc.so is still way
faster and more reliable than Vino, and I'm not sure how this would work
out for physically-headless VNC servers...)
- you are user who needs fine-grained configuration
(autoconfiguration
is good for masses but sometimes people needs more)
Runtime loadable modules, and fully dynamic runtime reconfiguration...
(But you guys probably know all this.)
Oh the future is bright, soon we will no longer be trailing
embarrassingly behind Windows and OSX, and take our rightful place as
leaders. :) Nice work, all Xorg hackers!
8:41 a.m.
On Wed, 2008-04-30 at 12:52 +1000, Rodd Clarkson wrote:
I've been running my system for the past week without an
xorg.conf file
and it seems to work well
I'm pretty sure that from comments made either on this list or
fedora-test that we are moving in a direction where the norm will be
that no xorg.conf file is needed and therefor won't be created.
I'm having discussions with someone about this at the moment and would
appreciate some clarification on where things are head so that this can
be addressed at their end.[1]
[1] The nvidia service from livna tries to
run /usr/sbin/nvidia-config-display which seems to require a xorg.conf
file in place. It appears that either (a) livna will need to work
around the absence of this file by creating one (how?), and eventually
(b) that nvidia will need to rewrite their software to recognize that
the file need not exist.
The driver selection heuristic is the open source native driver for the
hardware, if it exists, followed by vesa. Changing this (ie, to force
vesa, or to use a closed driver) requires writing a config file.
% system-config-display --noui --set-driver=nvidia
Will write a standard minimal config with the driver set to 'nvidia'.
- ajax
9:09 a.m.
On 30.04.2008 15:41, Adam Jackson wrote:
On Wed, 2008-04-30 at 12:52 +1000, Rodd Clarkson wrote:
> [1] The nvidia service from livna tries to
> run /usr/sbin/nvidia-config-display which seems to require a xorg.conf
> file in place. It appears that either (a) livna will need to work
> around the absence of this file by creating one (how?), and eventually
> (b) that nvidia will need to rewrite their software to recognize that
> the file need not exist.
The driver selection heuristic is the open source native driver for the
hardware, if it exists, followed by vesa. Changing this (ie, to force
vesa, or to use a closed driver) requires writing a config file.
% system-config-display --noui --set-driver=nvidia
Will write a standard minimal config with the driver set to 'nvidia'.
I suppose that will work if the user installed the drivers manually with
the nvidia-installer, as that simply overwrites some files from mesa or
xorg as shipped by Fedora.
It won't work properly with the livna driver-packages afaik as those
have to places some files in different directories (as we can't simply
overwrite files with rpm and don't want to) and do some magic with
/etc/ld.so.conf and a special ModulePath in /etc/X11/xorg.conf (¹) to
make the linker and Xorg find those files (otherwise 3d won't work with
the drivers; 2d will).
That's far from ideal and breaks quite often (for example with some
proprietary games that have a hard coded rpath to libGL.so.1). I hope
Fedora and Livna/RPM Fusion can work out a better solution in the future
to avoid that mess. Steward (he maintains the fglrx and nvidia drivers
in Livna) some months ago on this list suggested to switch to using
alternatives for libGL.so.1, but he didn't get much (or any?) feedback
on that. :-/
CU
knurd
(¹) -- that might become more complicated if there isn't any xorg.conf
11:07 a.m.
On 30/04/2008, Thorsten Leemhuis <fedora(a)leemhuis.info> wrote:
That's far from ideal and breaks quite often (for example with
some
proprietary games that have a hard coded rpath to libGL.so.1). I hope Fedora
and Livna/RPM Fusion can work out a better solution in the future to avoid
that mess. Steward (he maintains the fglrx and nvidia drivers in Livna) some
months ago on this list suggested to switch to using alternatives for
libGL.so.1, but he didn't get much (or any?) feedback on that. :-/
"/usr/lib/libGL.so.1" is, well, a well-established ABI, basically.
5845
days inactive
5847
days old
52 comments
29 participants
participants (29)
-
Adam Jackson -
Adam Tkac -
Ahmed Kamal -
Arthur Pemberton -
Bill Crawford -
Bruno Wolff III -
Callum Lerwick -
Chris Adams -
Chuck Anderson -
David Airlie -
Dennis Jacobfeuerborn -
Dmitry Butskoy -
dwight＠supercomputer.org -
Felix Miata -
Jeremy Katz -
Jerry James -
Jos Vos -
Kostas Georgiou -
Luya Tshimbalanga -
Luya Tshimbalanga -
Matej Cepl -
mike cloaked -
Nicolas Mailhot -
Rahul Sundaram -
Rodd Clarkson -
Roland McGrath -
Ron Yorston -
SL Baur -
Thorsten Leemhuis