Bug 224924

Created attachment 107705 [details]
y2log

Created attachment 107706 [details]
hwinfo --framebuffer

Created attachment 107707 [details]
hwinfo --gfxcard

Created attachment 107709 [details]
/var/log/SaX.log

Created attachment 107710 [details]
xorg.conf

Device is only supported by fbdev. framebuffer is set to 16bit, but you tried to configure 24bit. This cannot work.

Created attachment 107725 [details]
/etc/X11/xorg.conf.install (identical to xorg.conf.saxsave)

Created attachment 107726 [details]
/var/log/Xorg.0.log

Created attachment 107727 [details]
/var/log/Xorg.0.log.old

The X server runs on framebuffer and produces an unrecognizable picture now.
Apparently the framebuffer doesn't support 24bit, only 32bit (see hwinfo).
Nevertheless, SaX offered 24bit

Well, its actually two bugs
- UI deadlock (this bug)
- Offering to change color depth in framebuffer mode (-> bug 225019)

comment #6: Yes, I know. But a customer won't since 24bit is offered by YaST/SaX and there is no way to get out

Ah well sax2 handles that case correctly but I haven't had the time
to implement the fbdev check into yast2-x11. It is just there in the
library but not checked within the ycp code. Unfortunately Stefan had
to support a lot of devices using the fbdev driver because support
with an accelerated driver was gone. As result fbdev doesn't serve
as kind of fall back anymore but is used as alternative to some older
cards which in my opinion aren't really old. Anyway that's why we
stumbled over it more often now.

This is in fact an enhancement to the YaST x11 module and will be
implemented with high priority

Ack.
However, I cannot accept this as an enhancement since it effectively locks out the user from correcting it and it results in an unrecognizable display.
So I'm raising the severity back to major

Well, I wonder why DefaultDepth is set at all for a fbdev configuration. Does only make sense on ppc AFAIk.

1) Stefan if you are wondering why DefaultDepth is set why don't you tell
   it earlier ? DefaultDepth is ALWAYS set since years and it never was
   a problem not for fbdev and any other driver

2) Klaus if you don't change the color depth in your fbdev setup nothing
   serious happens. So how can this be a major problem ? If you change
   your bootloader to use the another than 16bit colordepth you could run
   into the same issue with fbdev X configuration. A major pane is the
   driver not the configuration

3) The hell why do I have to take care for broken fbdev implementations ?
   This is a nightmare even worse on ppc. If fbdev would work as it did
   some time before, DefaultDepth wouldn't make any difference. Why do you
   introduce a fbdev based setup on many cards without appropriate tests
   to the driver. Fix this damn driver and we can get rid of all nasty
   hacks without appropriate tests to the driver ?

It's far to late to waste time with that driver crap, will go to bed now

I don't think it's a broken fbdev driver. Unless you force a Defaultdepth via the config file the driver itself checks the current color depth and uses it. Klaus is probably the first user trying to change the color depth for a fbdev configuration. This is related to the missing open source native driver support for meanwhile very common gfx GPUs from ATI (> X1000). Therefore we didn't see this problem in the past. I agree that this should be checked in yast2-x11 as it is already done in SaX2.

Its a _usability issue_.

YaST offers to change to color depth.
So a customer will do what I did.
YaST _does_ detect that this is not possible (It shows "No proposal")
YaST does _not_ offer a way out.
-> Deadlock

- Stefan, almost all x11 drivers check their option and decide whether
  it makes sense to use it or not. Very often they make wrong assumptions
  and shouldn't be that intelligent but for fbdev it really would be easy
  to know that underlaying framebuffer layer cannot handle the color map
  allocated by the specified option. I would think this would be an useful
  enhancement for the driver itself

Anyway I made a patch for the x11 module because in principal you both are
right. The patch will be applied to the head branch of the x11 module.
Should this patch go into 10.2 ? It's a bigger patch as you can see.

Andreas please comment ?
Patch follows this comment 

Thanks

Created attachment 107832 [details]
yast2-x11.dif

Andreas and I just looked at the proposed diff. The fix looks pretty intrusive.

How about adressing the UI deadlock only ?
If a parameter change results in 'no proposal' revert to the old parameters.

Jiri, do you have someone to help verifying the correctness of comment #20 ?

your UI deadlock happens only on fbdev and is a result of libsax taking
care for fbdev but yast2-x11 doesn't. IMHO the best solution is I already
offered with the patch

Yes, it should be possible for the fbdev driver to ignore the DefaultDepth value in xorg.conf. Need to check this. 

I suggest to not allow another color depth for fbdev driver since it will make your Xsession even slower as it already is. 

Much more interesting would it be to allow to change the resolution. But this is enhancement Bug #220368. I would like to see this implemented for 10.3, since more and more ATI users will be affected by this problem.

package was checked in... fixed

*** Bug 225019 has been marked as a duplicate of this bug. ***