Problem changing monitor and mouse

[John]

Fabio Massimo Di Nitto wrote:
>

> | Other times when I've had the mouse definition wrong, the mouse moved
> | arratically. This time it didn't move at all.
> |
> 
> It can happen that too if the protocol are way too different.
Perhaps.
In _this_ case the configuration seemed to me to be consistant with what 
was written on the bottom of the mouse. It is a Microsoft mouse and it 
says intellimouse.

At different times mdetect returned two different values. I tried both 
in the XF config file and neither worked.

In contrast, when I installed Warty I did not need to provide any 
information about the (admittedly physically different) mouse.

> 
> 
> |>
> |> I think we have been discussing this issue already once.
> |> If something works for you, it does _not_ mean it works for everybody.
> |
> |
> |
> | Nore are we discussing everybody. I'm pretty sure I tried the info
> | ddcprobe gave me - I useually do when there is a problem - but if
> | ddcprobe can find it, I shouldn't need to specify it all.
> 
> I think you keep missing the point. ddcprobe does nothing more of what 
> the X
> driver does.
> 
> Both of them do a probe to the monitor.

In contrast, I think you re missing the point.

I have a graphics adaptor that is capable of 1600x1200 at 75 Hz. I 
checked the specs. The machine's  Dell GX110, Pentium III 666 on an 
Intel I810 chipset with integrated graphics.


It has a DDC-capable Sun monitor that is capable of (I thought it could 
do better, but I also thought it's a GDM-5410) that, so I expect to run 
it 1600x1200 at 75 Hz and _certainly_ better than the current 1280x1024 at 60.

I think this is the screen:
http://sunsolve.sun.com/handbook_pub/Devices/Monitor/MONITOR_Color_21_Prem_Flat_CRT.html



> If there are information back from the monitor it is good, but if there 
> are none,
> the 2 entries in the config will tell the driver: "Hey don't exceed this 
> values!"
> otherwise the driver will simply not know what to do.
> 
> What you are asking is simply impossible and the reason why we set sensible
> (and more or less standard defaults) is to avoid to fry old monitors that
> do not provide ddc information to the driver. And i am myself owner of such
> pieces of hardware.
> 
> Now, since nobody wants to take a chance to kill somebody else monitor, 
> i much rather
> prefer to set this value and sleep quite at night, than having somebody 
> knocking
> on my door because his flat screen burned.
> 
> If you are aware that all your hardware can sustain certain 
> configuration. you
> are welcome to set them as such.


What I expect is that configuring changed peripherals such as mouse and 
screen should be no more difficult than configuring them in the first place.




> 
> |>
> |> |
> |> | Had I done a fresh install it would almost certainly worked, and 
> worked
> |> | without me answering lots of Qs I should have to.
> |> |
> |> | Years ago, when RHL 7.2 was current I was changing monitors 
> regularly -
> |> | old ones too - and RHL reconfigured  automatically.
> |> |
> |> | Ditto with mice.
> |> |
> |>
> |> The todo list hasn't changed.
> |
> |
> | todo list?
> | Getting this right should be on the done list:-((
> 
> How would you implement it?
> 
> A lot of people are worried about linux taking too long to boot.
> How would you reconciliate another system probe during boot (that btw in 
> certain
> situation CAN hang your system) with the boot time?
> 
> If the user customizes the configuration, the probing system isn't 
> allowed to
> touch the config anymore. (Golden rule: always respect user changes)

That doesn't count. I didn't touch it until it didn't work.

> 
> How would you handle this?

I really don't know enough about how this stuff is done at install time 
to suggest how it could be adapted to post-install: my expertise was IBM 
S/370s running OS.


> This is a typical a non win to win situation. 50% of the people wants 
> the configuration
> automagically regenerated even with custom settings (how if changes are 
> clashing?), the
> other 50% will want it untouched. Considering all of this should be done 
> automagically..
> what path would you choose?

Ask?

A non-functioning system isn't an option. Neither is expecting much of 
the user.

Like so many others, I have been really impressed with Warty, but this 
problem dealing with a small change of hardware really is serious.

> Also.. if the system is a remote system and it gets hardware changes.. 
> you need
> to teach the admin that it needs a flag to disable hardware probing 
> otherwise
> the machine will never come up again.

I don't see that that follows. RHL (and RHAS/RHEL and Fedora) have been 
probing on boot for years. There were problems when Kudzu was new (I 
reckoned that naming it after a South American weed was appropriate), 
but it works well enough now.

Kudzu is at the heard of Knoppix's auto-configuration.

> Whilst it looks like a simple thing to do, it involves a lot of 
> different aspects
> and a bit of design that simply takes time to decide and to implement to 
> get it right.

Red Hat runs kudzu during boot. If it sees a physical configuration 
change it then changes the software configuration to suit.

Sometimes that requires user interaction (but it times out if there's no 
response), often it's no more than "Yes, reconfigure that."


I don't know whether you have anything in particular in mind, but if you 
haven't settled on a path forward yet Kudzu is certainly worth a look. 
ddcprobe uses it.

Kudzu's been ported to Debian, though I don't know just what "ported" 
means in this case. Running it isn't useful if the info it maintains 
isn't used, and it's not run on my system at boot time.

There is also the package system-config-display which was new when I 
last used RHL but which is used at install time and later to configure 
the display.

It may well "just work" on Hoary (it now configures xorg). It's GPL so 
there's no impediment to using it.

See http://fedora.redhat.com/projects/config-tools/