Bug 58469

Summary:

Display errors beyond virtual x-coord 2640 with dual screens

Product:

xorg

Reporter:

Tobias Frilling <tobias>

Component:

Driver/Radeon

Assignee:

xf86-video-ati maintainers <xorg-driver-ati>

Status:

RESOLVED MOVED

QA Contact:

Xorg Project Team <xorg-team>

Severity:

normal

Priority:

medium

Version:

unspecified

Hardware:

x86-64 (AMD64)

OS:

Linux (All)

Whiteboard:

i915 platform:

i915 features:

Attachments:

Description	Flags
possible fix	none
better fix	none

Description Tobias Frilling 2012-12-18 16:36:31 UTC

Hi there,

I found a strange problem today after connecting my new monitor to my computer.
With the new monitor I am using a multi monitor setup of size 3200 x 1080. But
it seems some applications are having troubles displaying anything beyond the
apparently magical line of the (virtual) x-coord 2640.
The troublemakers so far are:

- GVim
which renders no text beyond the magical line. This happens mid-character.
vim in a terminal behaves fine.

- Tint2
which shows no application icons in the system tray after 2640. Also happens
mid-icon. The clock has no problems. The rendering of icons in xfce4-panel
works strangely.

- MPlayer,MPlayer2, VLC, Skype
those freeze, but only in the "danger zone"; so they play a partially
frozen video

- xterm
same problem as with GVim. Other terminals (rxvt, Roxterm) are fine.

- Conky
Same as Gvim and xterm

Most other applications are not affected by this bug.

This problem seems to be independent from the window manager, as it occurs in
openbox-multihead, vanilla openbox, i3, dwm and awesome.

I am enabling my multihead setup via xrandr:
xrandr --output VGA-0 --auto --pos 1280x0 --output LVDS --auto --pos 0x280

Package infos:
- xorg-server 1.12.3.901-1
- xorg-xrandr 1.3.5-1
- libxrandr 1.4.0-1
- libxinerama 1.1.2-1
- xf86-video-ati 1:6.14.6-1

Further information:
xrandr output: https://pzt.me/7o17
Xorg.0.log: https://pzt.me/9fb4

Here are some pictures. As you can see, the text gets cut mid-character, but
strangely, the textdecoration is not affected.
http://img.vim-cn.com/af/ea943e3e903364fc9fc0d00d7ccd09f980bc40
http://img.vim-cn.com/ed/3ec2f5a955fefccbfa29d9d7b7356ea9669348

This bug doesn't happen if I configure the xserver statically
and use Xinerama.
10-monitor.conf: https://pzt.me/4xxr

Addendum: This is a copy of an older bug from the Arch Linux bugtracker but is still a problem with xorg-server 1.31.1 and xf86-video-ati 7.0.0. As I don't know wich part of X is to blame, I filed this under *Other

Comment 1 Alex Deucher 2012-12-18 16:59:05 UTC

You are hitting the hardware limits of the 3D engine on your card (X1200).  Your asic only supports a max render target of 2560x2560 and a max texture size of 2048x2048.  Randr uses a single large surface for multi-head and in this case, it exceeds the limits of the hardware.

Comment 2 Alex Deucher 2012-12-18 19:55:35 UTC

Created attachment 71748 [details] [review]
possible fix

Does this xf86-video-ati patch fix the issue?

Comment 3 Tobias Frilling 2012-12-18 20:16:16 UTC

Fixes everything but the MPlayer/VLC etc. video stuff.

Comment 4 Alex Deucher 2012-12-18 20:50:50 UTC

Created attachment 71750 [details] [review]
better fix

This should fix Xv as well.

Comment 5 Tobias Frilling 2012-12-18 21:10:15 UTC

Sorry, it does not.

Comment 6 Alex Deucher 2012-12-18 21:33:10 UTC

Are you using Xv video rendering?  If you are not using a compositing manager (i.e., Xv is rendering directly to the desktop), it won't work because the desktop surface is larger than the 3D engine coordinate limits.  I don't really know of a good way to avoid that other than refusing to render Xv if the surface is too big.

Comment 7 Tobias Frilling 2012-12-18 21:45:45 UTC

Yeah, I'm using the xv video output driver in MPlayer and i3 as my window manager, so no compositing.

Comment 8 Martin Peres 2019-11-19 07:39:45 UTC

-- GitLab Migration Automatic Message --

This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/xorg/driver/xf86-video-ati/issues/56.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.