Created attachment 14 [details]
xorg.conf of the generated system

xorg.conf of the generated system

What's the output of:
su
monitor-edid

Keywords: (none) => NEEDINFO

Created attachment 16 [details]
Output of monitor-edid

My bug report may be misleading. To reproduce, using the narrow - wrong
screensize - KDE screen obtained after system generation

1. systemsettings -> General -> Display
2. The Size pulldown menu offers only the 3 alternatives I mentioned, not the
1200x800 alternative I need. Apparently, KDE dis-regards xorg.conf and tries to
set the screensize to 1024x768.

In the meantime I have found a workaround:
- in the KDE session with the wrong screen-size do
   MCC -> Hardware -> Set up the graphical server

   MCC now shows the correct screen size (1200 x 800)

- now change the size to - say - 1024 x 768

- quit MCC, relaunch MCC and set the screen size back to 1200 x 800

After logout / login, KDE starts - now with the correct screen size
of 1200 x 800

The now correct setting is also recognised if I then start a KDE session for
another user, and it survives re-booting (to reproduce the original problem,
I guess that I will have to do a re-install)

Maybe that also provides some indication on the nature of the problem with KDE

IINM, XFdrake wrote a ModeLine to xorg.conf, and that made krandrtray (the tool in systemsettings) pick it up. To confirm please attach your current xorg.conf.

Created attachment 20 [details]
xorg.conf after applying the workaround actionis

Yes, that is the kind of scenario I am guessing at - and which made me try this kind of workaround.

You have the original xorg.conf (coming out of the installation) already in attachment #14 [details]. I now join a the xorg.conf as it came out after the workaround operation (attachment #20 [details]).

I compared the two: they are more or less identical, two items have changed:
HorizSync 28.8-90   changed to   HorizSync 31.5-50.0
VertRefresh 60      changed to   VertRefresh 56.0-65.0

Some more facts:
- When I switch back and forth between the initial ("bad") xorg.conf and the new xorg.conf (made with the workaround) I can make the problem come and go - perfectly reproducible

- But: the "bad" Monitor section of Mageia 1 looks like a precise copy of the Monitor I have in my 2010.1 system

Bug still present in beta - and still very annoying

Is it still present with the last kdebase4-workspace, we did some changes on the startkde script regarding the way xrandr is called (following in fact upstream kde)

CC: (none) => balcaen.john

I observed the bug on systems just after install - never tried to figure out a way to reproduce the bug on a customized running system.

I am presently travelling - difficult to do an install right now. I can easily check next Thursday (beta2 will probably we ready for an install by then).

I now did a fresh install of Mageia 1 Beta2: The bug persists - no progress.

What can I do to help clarifying this problem?

The problem still exists in RC1

Well we did not have many changes regarding that in kde :/

The problems only affect KDE or it's happening in GNOME too (& other DE) ?
If it's related to wrong xorg.conf, did you try to boot without xorg.conf ?
It's happening with only a specific monitor ? or on several monitor?

1. Only KDE or also GNOME?
   I now built a system with Gnome: same problem. In fact: the problem (the 
   display not filling the entire screen) is already present at the login
   screen - i.e. before gnome or kde get started (but the same narrow display
   than is maintained when the DE comes up).

   I had not realised this when I submitted the bug - sorry, that looks
   essential.

2. Boot without xorg.conf
   How do I do that? please help!

3. Only on specific monitor?
   I dont know - the problem only appears on my laptop. I could try with
   external monitors - if that is worth the while. I have practically the
   identical system on my desktop (1600x1200 bits) - there everything is OK

(In reply to comment #16)
> 1. Only KDE or also GNOME?
>    I now built a system with Gnome: same problem. In fact: the problem (the 
>    display not filling the entire screen) is already present at the login
>    screen - i.e. before gnome or kde get started (but the same narrow display
>    than is maintained when the DE comes up).
> 
>    I had not realised this when I submitted the bug - sorry, that looks
>    essential.
Ok so it's not KDE related :)
Maybe it's a xorg problem or a XFdrake one ( if everything is ok without the xorg.conf it's more a problem with XFdrake i would say)

> 2. Boot without xorg.conf
>    How do I do that? please help!

Simply remove the /etc/X11/xorg.conf (via a mv xorg.conf xorg.conf-old for example) & restart your X session

> 3. Only on specific monitor?
>    I dont know - the problem only appears on my laptop. I could try with
>    external monitors - if that is worth the while. I have practically the
>    identical system on my desktop (1600x1200 bits) - there everything is OK

It can also be cause by some wrong info provided by the monitor.

Source RPM: kdebase4-workspace => xorg-x11-7.5-7.mga1.src.rpm

Thanks. I did not know that it is possible to run without xorg.conf:

Without xorg.conf the problem does not show. I again (now under RC1) compared the xorg.conf produced by system install (which gives the faulty result) with the xorg.conf obtained after applying the workaround (comment #5). The only difference are the sync rates

the correctly working xorg.conf has:
    HorizSync 31.5-50.0
    VertRefresh 56.0-65.0

and the faulty one:
    HorizSync 28.8-90
    VertRefresh 60

Simply substituting these rates makes the faulty xorg.conf work correctly.

What I have problems understanding is: the workaround (comment #5) simply forces the utility that generates the display section of xorg.conf to be called - which produces the correct result. I guess that system generation uses the same utility (does it really?) and that time it gets it wrong.

That gives me an idea: I will yet once more install a system, but not use automatic display configuration - see what happens. I will post the result

Starts to look somewhat clearer: Launching a new install, in the Summary page, I did not accept the automatically configured display configuration but:

1. I went into the "Graphical interface" tab
   It says Monitor: Flat Panel 1280x800
           Resolution: Automatic

2. I modified "Monitor" and "Resolution" to 1024x768
   After hitting next, the summary shows the new dimensions, for the sync rates
   it says 31.5-48.0 (horizontal) and 56.0-65.0

3. I went back into the "Graphical interface" and set the Monitor back to
   1280x800 and the Resolution to automatic.

After this devious display configuration setup, boot provides a correctly working
display, with an xorg.conf that looks like an exact copy as the one I obtain by applying comment #5 workaround.

The culprit therefore appears to be the system generation, i.e. the automatic setup of the display configuration.

That means that the title of this bug is wrong - misleading for users who do a search. Can you modify the title? shall I re-file a new bug? or just leave things as they are?

You can do it by yourself clicking on edit :)

Thanks - just as easy as asking silly questions -)

(In reply to comment #5)
> In the meantime I have found a workaround:
> - in the KDE session with the wrong screen-size do
>    MCC -> Hardware -> Set up the graphical server
> 
>    MCC now shows the correct screen size (1200 x 800)
> 
> - now change the size to - say - 1024 x 768
> 
> - quit MCC, relaunch MCC and set the screen size back to 1200 x 800
> 
> After logout / login, KDE starts - now with the correct screen size
> of 1200 x 800
> 
> The now correct setting is also recognised if I then start a KDE session for
> another user, and it survives re-booting (to reproduce the original problem,
> I guess that I will have to do a re-install)
> 
> Maybe that also provides some indication on the nature of the problem with KDE

This workaround did not solve my problem.  Now I still have a panel "sinking" below my screen.  And I think that's why I always got two notification bubbles.

I also compared my xorg.conf before and after the workaround.  No any difference.

CC: (none) => franklin

(In reply to comment #22)
[...]
> 
> This workaround did not solve my problem.  Now I still have a panel "sinking"
> below my screen.  And I think that's why I always got two notification bubbles.
> 
> I also compared my xorg.conf before and after the workaround.  No any
> difference.
Without knowing your configuration setup (aka do you use the same laptop, do you use the same graphic card, etc etc), it's quite impossible to say if you're affected by the same problem & so if the « same » workaround could fix it.

(In reply to comment #23)
> (In reply to comment #22)
> [...]
> > 
> > This workaround did not solve my problem.  Now I still have a panel "sinking"
> > below my screen.  And I think that's why I always got two notification bubbles.
> > 
> > I also compared my xorg.conf before and after the workaround.  No any
> > difference.
> Without knowing your configuration setup (aka do you use the same laptop, do
> you use the same graphic card, etc etc), it's quite impossible to say if you're
> affected by the same problem & so if the « same » workaround could fix it.

I just found out where my invisible panel is.

Just now, I found that it was resided in the top of another KDE activity.
To be more precise, it was not a panel anymore.  All the plasmoids in my original panel was set in the top of the activity desktop.  I removed them all and my KDE notifications works fine now.

I think that there is really resolution problems when upgrading.
My problems might still be similar to this one.

Originally my screen resolution was incorrect, and the panel was out of my screen.  Then I tried to change from my original 17" to a 19" screen and make it auto-detect the screen resolution again.  The resolution then seemed to be correct this time.  That's why my xorg.conf didn't change I guess.

However, since now my system works, I may not be able to provide any useful information to you now...

Is xrandr installed at all? (might be similar to bug 1640).

No, xrandr is not installed in my system - but not my choice, comes out of system install like that.

Following up your comment, I did a fresh install (necessary to put the problem in evidence - my operational system has a correct display due to applying the workaround), adding xrandr to the list of packages to be installed during system generation: nothing changed, even with xrandr installed, the display has the wrong dimensions.

OK, thanks for testing, it's not related to bug 1640 then.

There is a new fact, though: even with many new users installing Mageia when the release came out, the bug has apparently not been reproduced

The problem appears to be either due to some fault I make (but I do not see what I could have done wrong - it happens immediately after system install), or is specific to something very special in my laptop.

(In reply to comment #28)
> There is a new fact, though: even with many new users installing Mageia when
> the release came out, the bug has apparently not been reproduced
> 

Because of that and because the workaround worked for you, I'm closing this bug

Status: NEW => RESOLVED
CC: (none) => m.van.waes
Resolution: (none) => WORKSFORME

For the record: for a Dell D820 laptop, the bug is still present in Mageia 2 Beta 2. The workaround described has become more complicated: you need to reboot after each modification of the MCC graphical server setup.