On Tue, 2004-11-30 at 19:44 +0000, Alan Cox wrote:
> Mobility Electronics have been shipping cardbus hotplug video for about
> 5 or 6 years now (E1000V). They make fun toys for this sort of testing
> and are cheap on ebay generally 8)
Hotplug of displays is way more common than that; consider the laptop
case, where you want to sometimes plug in a projector and just mirror
the main display (which mostly works now) but sometimes you want to plug
in a second monitor for extra screen real estate and expand your desktop
onto it, and most of the time you just have the laptop display. At least
I haven't found a way to do the switch without an X restart but I guess
I might have missed something (can RandR help with this simple case)?
Of course, if the general hotplug case is taken care of, reconfiguration
of a graphics card on the fly will probably basically be solved
automatically as part of that so that's definitely the real solution;
however, some work and testing might be possible even without somewhat
exotic hardware.
/Per
--
Per Bjornsson <perbj <at> stanford.edu>
Ph.D. Candidate, Department of Applied Physics, Stanford University
--
--
fedora-devel-list mailing list
fedora-devel-list <at> redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list

On Tue, Nov 30, 2004 at 04:25:54PM -0800, Per Bjornsson wrote:
> Hotplug of displays is way more common than that; consider the laptop
> case, where you want to sometimes plug in a projector and just mirror
> the main display (which mostly works now) but sometimes you want to plug
This is a hotplug video card rather than hotplug video ports. Its a cardbus
bridge with an ATI rage based device behind it.
Alan
--
--
fedora-devel-list mailing list
fedora-devel-list <at> redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list

On Tue, 30 Nov 2004 13:23:42 -0500, Jim Gettys <jim.gettys <at> hp.com> wrote:
> David,
>
> I agree with you and Kristian and I have started work, specifically on
> the input system side to do exactly what you suggest. Similar
> work ought to be done someday for the screens themselves (hotplug being
> a reality even for screens; today with PCMCIA and PCI express is just
> beginning to ship).
>
> And yes, everything needs to be dynamic, rather than static, to the
> extent possible.
>
> However, we'll still probably need some sort of configuration system
> for "non-standard" situations. It may be something other than the
> current config file will be desirable for this...
While pulling out the config from the server itself, and making the
server respond to events on the fly through that mechanism, still
leaves the design and policy of the config program up in the air.
I always envisioned something like the existing getconfig system,
except not sucking (ie, no Perl needed for what are essentially config
files).
The config client iterates over a few directories containing bits of
config data, which pair settings to pci IDs and event types. Vendors
can specify create these little mini config files and ship them with
drivers. For example, for a bogus chip, called the Bogart3D, we have a
/usr/share/X11/bogart3d.cfg

Re: i486 base architecture

William M. Quarles <quarlewm <at> jmu.edu>
2004-12-01 02:56:23 GMT

Arjan van de Ven wrote:
> On Tue, 2004-11-30 at 12:05 -0500, William M. Quarles wrote:
>
>>performance difference. Now were you saying that this cmov is part of
>>i486 or i686?
>
>
> i686
What differences between i386 and i486 would become a benefit if the
base architecture was changed from i386 to i486?
----
Thanks,
William
--
--
fedora-devel-list mailing list
fedora-devel-list <at> redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: i486 base architecture

Alan Cox <alan <at> redhat.com>
2004-12-01 03:00:26 GMT

On Tue, Nov 30, 2004 at 09:56:23PM -0500, William M. Quarles wrote:
> What differences between i386 and i486 would become a benefit if the
> base architecture was changed from i386 to i486?
The only thing 486 might give is the ability to consign the old linuxthread
stuff to the dustbin of back compatibility.
--
--
fedora-devel-list mailing list
fedora-devel-list <at> redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list

Re: adventures in booting

Ziga Mahkovec <ziga.mahkovec <at> klika.si>
2004-12-01 02:59:58 GMT

On Sun, 2004-11-28 at 20:49 -0500, David Zeuthen wrote:
> So, I've looked a bit more into the booting process and how to optimize
> it.
Great work!
> The results are pretty good I think, here is the general time line made
> with a wallclock
>
> 00: exit grub; start booting the kernel
> 04: kernel prints audit()
> 11: initrd is mounted; Red Hat nash visible
> mount / ro (normal initrd procedure)
> 13: start bootchart logging; start readahead of approx 193MB files
> sleep until readahead is complete
> 24: readahead done; now
> create /dev and modprobe (in background)
> mount / rw, enable swap
> start xfs
> startx as user davidz in background
> start messagebus
> start hald
> start acpid
> start NetworkManager
Do you have an idea of how much kudzu, cups and syslogd would add to
these times? rhgb too probably, or would it make sense to dump it
completely?
> 7. A number of things was started in parallel - I found that doing

Re: i486 base architecture

William M. Quarles <quarlewm <at> jmu.edu>
2004-12-01 04:06:21 GMT

Alan Cox wrote:
> On Tue, Nov 30, 2004 at 09:56:23PM -0500, William M. Quarles wrote:
>
>>What differences between i386 and i486 would become a benefit if the
>>base architecture was changed from i386 to i486?
>
> The only thing 486 might give is the ability to consign the old linuxthread
> stuff to the dustbin of back compatibility.
I'm guessing that's supposed to be a joke?
----
Peace,
William
--
--
fedora-devel-list mailing list
fedora-devel-list <at> redhat.com
http://www.redhat.com/mailman/listinfo/fedora-devel-list

Dave Jones wrote:
> On Tue, Nov 30, 2004 at 11:36:23AM -0500, William M. Quarles wrote:
> > Dave Jones wrote:
> >
> > <snip>
> > > > C. If it doesn't hurt and it would probably help, I don't see what's
> > > the > matter with making an Athlon-optimized kernel.
> > >
> > >A number of reasons.
> > >- It's one more column in the matrix of supported kernels to worry about.
> > > This may seem insignificant, but it takes quite a while to push
> > > a kernel package through the buildsystem given how many variants
> > > it spits out. On a busy day (like for eg, just before release), it
> > > can take the better part of a day to get packages built.
> > >- The gain just isn't worth it over the 2.4 kernels.
> > > Now that the runtime optimisations get performed in 2.6, theres only
> > > one thing thats missing that would be in an Athlon optimised kernel,
> > > and thats the optimised copy_page/clear_page, which are really only
> > > a win when a lot of data is being copied back/forth between the kernel,
> > > and even then, only under certain usage patterns. I'll be surprised
> > > if this shows up on any real-world application.
> > <snip>
> >
> > Apparently the man who started this thread found his real-world
> > applications.
>
> I don't see any numbers. There's also nothing specifically
> indicating that building for Athlon is why he saw a performance
> win. If something else also got disabled (even inadvertantly),
> that could also factor into it.