Bug 492321 - display messed up (box instead of mouse, no background, poor readrawing)
Summary: display messed up (box instead of mouse, no background, poor readrawing)
Status: CLOSED RAWHIDE
Alias: None
Product: Fedora
Classification: Fedora
Component: xorg-x11-drv-nouveau
Version: rawhide
Hardware: All
OS: Linux
high
high
Target Milestone: ---
Assignee: Ben Skeggs
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2009-03-26 13:24 UTC by Michal Hlavinka
Modified: 2009-05-04 20:13 UTC (History)
5 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2009-05-04 20:13:31 UTC


Attachments (Terms of Use)
Xorg.0.log (113.61 KB, text/plain)
2009-04-01 11:10 UTC, Michal Hlavinka
no flags Details
~/.xsession-errors (4.55 KB, text/plain)
2009-04-01 11:12 UTC, Michal Hlavinka
no flags Details

Description Michal Hlavinka 2009-03-26 13:24:29 UTC
Description of problem:
After X start there is login window with some images/drawings missing and no (or not visible) mouse cursor.

After login there is no background, box instead of mouse cursor an redrawing of the screen is poor (boxes sometimes)

Version-Release number of selected component (if applicable):
hw Quadro NVS 290 [10de:042f] (rev a1)
http://www.smolts.org/client/show/pub_f30a83d0-41c9-4a0f-ac45-8212f8d78098

How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
using 2 LCDs

Comment 1 Adam Williamson 2009-03-27 21:09:09 UTC
Does it behave any differently if you try it with KMS?

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 2 Michal Hlavinka 2009-03-31 08:59:45 UTC
(In reply to comment #1)
> Does it behave any differently if you try it with KMS?

yes, system gets frozen

1)without kms

messed display (see bug description), unusable but system works

2)kms and 2 LCD (first wide, second normal)
during the boot, splash is visible, but

- it's not completely smooth (I don't know if it should be) = in about one third of the progress it blinks once

- window on the first screen is not wide - empty place on the right side, this is fixed just in the end of the boot

- after progress bar reaches the end, splash stops the animation and after few seconds both lcd goes black, system doesn't respond to mouse, keyboard, power button

3)kms and one LCD
- situation is the same, but splash covers wide screen completely

---------------

after reboot to init 3, Xorg.0.log is empty

tested with updated nouveau driver

fast user switching works, but display is messed up even more (missing fonts)

X server restarting makes no difference

Comment 3 Adam Williamson 2009-03-31 19:04:09 UTC
Thanks. Can you attach the usual log files (/var/log/Xorg.0.log , possibly ~/.xsession-errors if there's anything interesting in it) and then we can assign this? Thanks!

-- 
Fedora Bugzappers volunteer triage team
https://fedoraproject.org/wiki/BugZappers

Comment 4 Michal Hlavinka 2009-04-01 11:10:47 UTC
Created attachment 337488 [details]
Xorg.0.log

tested with xorg-x11-drv-nouveau-0.0.12-20.20090330git9d46930.fc11.x86_64 and xorg-x11-server-Xorg-1.6.0-16.fc11.x86_64

Comment 5 Michal Hlavinka 2009-04-01 11:12:35 UTC
Created attachment 337489 [details]
~/.xsession-errors

xsession-errors is probably useless

Comment 6 Adam Williamson 2009-04-01 21:16:51 UTC
thanks a lot.

Comment 7 Ben Skeggs 2009-05-04 03:27:32 UTC
Can I grab an update on how things are with current versions of xorg-11-drv-nouveau and the kernel?  If things are still bad, fresh logs would be useful as things have changed a little since the last lot.

^ - it's not completely smooth (I don't know if it should be) = in about one
^ third of the progress it blinks once
It should be smooth, and is in the situations I've seen so far.  If X decides to choose a different mode for your displays as it starts however, it may flicker there.

^ - window on the first screen is not wide - empty place on the right side, this
^ is fixed just in the end of the boot
This is the intended behaviour.  fbcon will attempt to program all displays to their preferred modes to avoid a modeset as X starts (for the smooth transition to X).  Unfortunately, fbcon expects a single framebuffer, so you get a framebuffer the size of the smallest screen.

Comment 8 Michal Hlavinka 2009-05-04 13:48:04 UTC
(In reply to comment #7)
> Can I grab an update on how things are with current versions of
> xorg-11-drv-nouveau and the kernel? 

Updated rawhide works (tried: playing video, modeset and dualhead)

> ^ - it's not completely smooth (I don't know if it should be) = in about one
> ^ third of the progress it blinks once
> It should be smooth, and is in the situations I've seen so far.  If X decides
> to choose a different mode for your displays as it starts however, it may
> flicker there.

it's smooth now

I think you can close this bug now


Note You need to log in before you can comment on or make changes to this bug.