linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: David Brownell <david-b@pacbell.net>
To: linux-hotplug@vger.kernel.org
Subject: Re: Hotplug can configure XFree86
Date: Fri, 28 Dec 2001 04:51:49 +0000	[thread overview]
Message-ID: <marc-linux-hotplug-100951528129787@msgid-missing> (raw)
In-Reply-To: <marc-linux-hotplug-100923910820843@msgid-missing>

> Well, things that hotplug can't currently guess (as used in an
> X config)

There are lots of things, and some of them _could_ in some
cases be autodetected ... or at least old values saved and
reused (likely after sanity checking).  In particular, don't many
of the newer monitors have ways to identify themselves?

> - monitor type
>   (which lets you get the available resolutions and depth)
> - users's preferred resolution
> - users's preferred color depth
> - pointer type (for non USB, etc.)
> 
> I realize I have a biased opinion, but I don't think that walking
> the user through a minimal X reconfiguration (as opposed to a
> completely automated change) is a bad thing on graphics HW change.

I don't either, and in fact I'm convinced that there are some
configuration actions that deserve user intervention ... even
at the level of popping up some dialogue on the user's X11
desktop, and presenting notices (and ideally actions)!

But on the other hand, I also believe that should be avoided
whenever possible.  So for example in this case, I'd rather
see a "looks like you have <this/> new configuration, right?"
dialogue rather than doing twenty questions.  (Though to be
sure, the last few times I had to do the xf86config-ish game
the questions were at least ones that mortals might answer!)
And sometimes that dialogue would be able to time out
without demanding input...

I'm making a fairly general point here, which I hope most
folk will agree with:  Linux desktop systems should do a
lot more "automatic detection" of hardware ("hotplugging")
than they've traditionally done, and demand a lot less user
input on configuration changes.  It's been getting better in
the past few years ... and I hope it'll continue !!  Likewise,
I'll hope that the distros will converge on at least the tools
in those areas, if not all the policies they use.  That's harder.

- Dave



_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

  parent reply	other threads:[~2001-12-28  4:51 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-12-25  0:11 Hotplug can configure XFree86 Stamatis Mitrofanis
2001-12-27 20:32 ` David Brownell
2001-12-27 23:00 ` Stamatis Mitrofanis
2001-12-28  1:10 ` Bill Nottingham
2001-12-28  4:51 ` David Brownell [this message]
2001-12-30  3:23 ` Stamatis Mitrofanis
2001-12-30  3:56 ` Miles Lane

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=marc-linux-hotplug-100951528129787@msgid-missing \
    --to=david-b@pacbell.net \
    --cc=linux-hotplug@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).