Bug 12596
Summary: | kernel modesetting: text rendering in rxvt really slow | ||
---|---|---|---|
Product: | Drivers | Reporter: | Florian Mickler (florian) |
Component: | Video(DRI - non Intel) | Assignee: | drivers_video-dri |
Status: | REJECTED INVALID | ||
Severity: | normal | ||
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.29-rc3-00324-g45c82b5 | Subsystem: | |
Regression: | --- | Bisected commit-id: | |
Attachments: |
dmesg startup without kms enabled
dmesg startup -- kms enabled lspci -v output normal xorg startup xorg startup with kms enabled |
Description
Florian Mickler
2009-02-01 08:40:29 UTC
Created attachment 20061 [details]
dmesg startup without kms enabled
Created attachment 20062 [details]
dmesg startup -- kms enabled
there is some 1400x1050 mentioned, but not set...
Created attachment 20063 [details]
lspci -v output
Created attachment 20064 [details]
normal xorg startup
fyi
Created attachment 20065 [details]
xorg startup with kms enabled
this starts up in 1024x786 and xrandr --output LVDS1 --auto sets it back to 1400x1050, but the picture just gets pushed into the topleft-edge... not rescaled...
Do you have the framebuffer console driver builtin or loaded? If not, i915 won't paint anything on the screen and will leave your display off. Also without another graphics configuration to switch to, the X contents will be left alone by the kernel, so you won't see anything change (X probably won't draw to it much while VT switched), so this could be normal. The slowness you see with text rendering could be an UXA problem (it doesn't map pixmaps through the GTT in the KMS case). ah yes. with framebuffer console driver, the console works. nice. thx. (xorg: exa has corruption issues, the uxa-text-rendering slowness with kms persists...) i'm back now at my dockingstation with attached vga output.. which brings me to the further questions: how is dualhead supported at the moment? because there are some issues, modesetting wise : it best works if i switch platformwise to the internal display while the laptop-firmware is in dos-mode (before grub hands off control). then kms sets my internal display nicely up and my vga is in clone-mode if my vga is firmware-wise the primary output, then the lvds is somehow funny white (in a way which makes me wonder if it is healthy to the hardware) and the vga gets the same mode set as the lvds before (which leaves the black borders, which i tolerated in clonemode... ) if x starts up, the graphics are unsharp until i xrandr --auto the vga1 (which clears up vga1, but doesnt scale it up, which seems like bad modesetting<->xorg interaction) xrandr on lvds1 doesn't work and gives errors... sorry for misusing this bugzilla to satisfy my curiosity and thx for your reply. and sorry if i don't express myself clearly or misuse vocabulary: i'm no mode-setting hacker and no native speaker hi, i just tested i915.modeset=1 again with rc-8 + eanholt/intel-drm-next for my dualhead setup i amended the xorg.conf driver section to use the right monitor-sections (because of the rename LVDS -> LVDS1 and VGA -> VGA1 that wouldnt work anymore) that leaves no problems for me besides the last point: it seems the only real (persisting) problem in my bugreport was the slow rendering of text. this is with rxvt as virtual terminal. xterm, konsole and gnome-terminal all do not exhibit this slowness (5-10 secs to display dmesg) i've installed from current git: dri2proto inputproto libdrm libXcomposite libXdamage libXext libXfixes libXrandr mesa pixman randrproto xextproto xf86-input-evdev xf86-video-intel xorg-server What should I do to get rxvt back up to speed? (i assume, that there are other programms which exhibit the same problem... but haven't found anything) do you need more info? should we close this bugreport and open a new one? Yeah, the rxvt slowness is probably not a kernel problem but an UXA problem of some kind. Please close this one out and file a new bug at bugs.freedesktop.org. PEBCAK |