Bug 413083

Stefan is this possible?

I don't understand this issue. Scott, could you please try to explain it more detailed? What are you doing, what do you expect to happen?

Thinking about it again. This is in the responsibility of the desktops like KDE(3/4), Gnome, Xfce, ... to detect this and ask the user if he wants to start
SaX2 to configure this setting permanently.

Stefan you are correct!..Just as inserting a new USB Printer SAX2 detects the new device and asks the user if they want to permanently add/change and optionally [("Keep User Informed of Changes)" or a similar check box question]  You can demonstrate this by plugging into a running system, any USB Printer or scanner.

If you are going to modify sax2 do you want to include item 2 below?? - Your thoughts??


#2There is also an issue with adding speakers (non USB) after an install being not detected - do you want me to open a new bug or change title as I would think sax2 would be responsible for a change/addition of speakers??? 
My current system had speakers added and I can not configure or detect them or try my luck with a brand name of card/speakers!

Item 2 needs to be handled seperately. SaX2 is not responsible for configuring your sound system. And it's the desktop system, not SaX2, to detect a changed monitor and then possibly ask the user to run SaX2. I suggest to assign this bugreport to the appropriate component of your favorite destkop.

Okay then, what is you favorite desktop?

What ? 

I finally got my head together and realized you did not want to know my favorite brand of PC or screen saver.....Please don't be frightened I am not that stupid at first thought I had in response to your question.
I love and maintain a
OS:  Linux 2.6.22.18-0.2-default x86_64
Current user:  ids000@MULTIVAC-IDS001
System:  openSUSE 10.3 (x86_64)
KDE:  3.5.7 "release 72.9" 
In fact the issue of a total NON Plug and Pray type scenario even permits that installation of an incorrect vendor variation of display Driver.
For example If you change Monitor, this change in hardware is NEVER RECOGNISED as being changed and the previous display driver, taken from Build Services, objects, but cannot detect a change at the screen size and aspect and driver of any change in Monitor.
I realize this may be difficult to solve because its not a change in USB, however much needs to be done in this area as a user can happily go unchallenged in changing the display driver from current to something else meant for a different video card via build services, a situation which represents huge issues in both KDE4 and SAX2, qt5 and compiz config session manager.

Moving to KDE maintainers to consider if this can be implemented in KDE.

1.Without fixing this issue in Video Monitor and cards AGP/PCI/PCIE. We may as well to stop shipping Suse 11.0. RC

Install few otatwendute only available to select correct video/sound/land card at time of Interrogation of Hardware and installs the best SUSE for this video Card and ignore the drivers available in backend repositories. It should NOT THEN be able to select the different driver, and than PS2 Devices selects the best Video based on the assumption of an Video Card for Chucho Install should gave access, in the first instance.

RE#10
KDE Maintainers ???
I thought this would sit on Yast - Hardware AND Install UPDATE - as the function of exploring the Display Hardware is already functional in 11.0 NEW Install Program and work very well.
If Implemented in Yast would suggest offer option to "Disable Hunt for New Display Hardware" to speed up boot process as default ON.
Please consider this as applicable to NEW Speaker Hardware OR do you wish a NEW Bug Enhancement request.
Again If implemented please consider option to "Disable Hunt for New Speaker Option" as default ON.
[(secure password ON) Hate intrusions who are NOT ME...but make a good try at mimicking voice]

As Stefan said this is something that should be implemented in desktop manager (eg. KDE, Gnome, Xfce...) that would detect change and ask to run sax2. I can either move this bug back to KDE maintainers to consider to implement this or to yast2 maintainers (and most likely this bug will come soon back to me).

And the speaker feature seems as not enough identical problem, so please open new bug for this.

I would strongly oppose changing any hardware items to within each desktop.

Yast in logic, sets down the hardware,software and is Percived and functionally the best and only place for hardware changes.

As desktop do and will change you have 1 and only 1 place to go to setup hardware, video, sound etc - Yast you can be assure it will function correctly.

I know Yast do not like changing anything that they have already decided on and I understand your reluctant.

I would like you to sent to Yast..If it comes back WONTFIX - Its o.k I will wish no further changes to the current effective support on USB devices but there is NO support for change in Monitors, PS2 connections. Paralleled and serial connection et changing Display Monitors e changing Monitors.

What makes this request so simple is that you already have the code written in Install which goes looking for ALL devices and selects drivers et cduring install to get up minor, scanners, Parrnell or Serious

Hopefully it will come back with needinfo or assignment

Thanks QA for you help and wise words

What are you going to say to a Netadmin with SLED that the monitors in the business need changing as defective. Are you going to tell a customer the is no functionality to detect and auto configure a new Display Monitor and the software cannot detect NEW Display OR Video cards etc and NOT auto configure the new monitor

Scott

Other issues in changing Monitor. If a Supported Video card is working fine and the monitor goes U/S or is upgraded to a wide screen with a different aspect ratio, square vs Wide screen - what happens there?

Also if the user accident changes the auto detection of the Video Card or it is replaced, how is the system going to reassess both a new video card and assign a correct driver in the case of user change in error and want to return to correct support for video card AND/OR upgrades from a AGP to PCI or PCI/PCIe.

Most motherboards have inbuilt Video support of High Quality and lets say the user decides to install a new high performance Video Card for Games ...say a PCIe card and turn of inbuilt card in hardware - How does Suse handle change in NON USN changes such as all of the above.

This area os system change must surely sit with Yast...To suggest that the desktop dictate to yast is not reasonable.


The samba server in Yast can be dictated by KDE Kcontrol setting to  change any shared directory and I still have an outstanding bug in this respect.

With all respect its time all developers at Suse.DE stop using the command prompt and use the HUI first and foremost and leave the command prompt as last resort.

So many Bugs/Issues arise post release as there developers dont use the same GUI tool the users use. - To save time they all use a command prompt - This philosophy MUST change at a Change Management Perspective.....and yes I had had a bad day...sorry;-(

You are wrong, many developers (including me) use GUI tools.

I don't know how and where it should be solved. Marcus any idea?

Let me first tell you Scott that in the past we had a check at boot
time if the hardware has changed (hardware ID's) If that happened sax2
was called in re-init mode and provided a clean new proposal for the
_complete_ X11 subsystem. So if the user plugged in a new monitor he
got a new proposal, if he plugs in a new mouse using its own mouse driver
the same happened. The short answer to all this was "people hated it"

  * they don't want some magic at boot time
  * they don't want to setup their custom resolution just because the
    mouse has changed

To some degree I can understand that but it would also be a bad idea to
handle the different parts of the X11 subsystem as unique entities because
they aren't unique. Many of them conflict with each other and you can't
compare the old situation with the new one without creating other problems
and that even applies to the mouse. The best example is a synaptics touchpad
which can't be the core mouse so if you had a standard mouse before the
system will break by that change without a new configuration. You can
claim that are bugs in X and most probably you are right but I spent a
couple of years to find out that nobody cares of that kind of problems
people stumble over.

We decided to offer a complete setup which we can control and which we can
offer as _working_. But we disabled the reprobe code at boot time because we
had to

A possible solution seems to happen in X itself. The possibility of the
X-Server to probe and Identify changes at startup and the removal of the
static configuration file xorg.conf will allow people to change everything
and they can use GUI applications to change other data on the fly

I think this is the way to go for the future.

I fully agree with Marcus here. Dynamic configuration will happen once it's no longer required. Other distributions are already trying this, but I still see a lot of problems there, so I wouldn't recommend to do it right now. Most of them needs to be addressed upstream in X.Org project ==> UPSTREAM