[aur-general] TU Application: Jiachen Yang (farseerfc)

[Jiachen Yang]

On 11/06/2015 04:38 AM, Pierre Neidhardt wrote:
> Just out of curiousity: why are you maintaining awesome34?
> Is there something that got lost on the way to 3.5?
> 

Short answer: Yes, the upstream of awesome 3.5 dropped the support for
multiple screens (in X protocol term, not the general meaning of
"screen" in English). There is a bug report to track this in their old
issue tracking system [1], which is the only remaining issue that marked
"critical" and remains unsolved.

Long answer:

I have a relatively rare X multihead setup [2] on my workstation. It has
two identical graphic boards (ATI FirePro V3700), each connected to two
monitors, without a crossfire cable in between. Awesome 3.4 is the only
WM that can drive this setup sanely in my knowledge.

Awesome 3.5 removed support for this setup intentionally, as I quote
from the issue comment [3]:

> This was not by accident. This was me removing something which I can't
> test, which was buggy and which complicated the code a lot (now there
> is just a single pixel at coordinates 0x0 instead of one per screen).

I tried to use Xinerama/Xrandr for some time.

Xinerama itself is painfully slow and buggy to be use, because of the
software rendering. I cannot get OpenGL on Xinerama, and even typing
code in Eclipse is a pain in Xinerama. Further, Xinerama don't seem to
understand monitor rotation and will enter a strange pining mode, so
that I have to patch the Xorg to disable that mode in order to use Xinerama.

Xrandr can use GPU and renders much faster, but xrandr can only utilize
a single GPU. Xrandr 1.3 and previous cannot use 2 graphic boards at
all. Xrandr 1.4 add the ability to render in one card and use another
card as the output sink. I was excited at the time that xrandr 1.4
arrived in Arch Linux and tried it as soon as possible. I was able to
use 3 monitors, 2 connected to the rendering card and 1 connected to the
sink card. But as soon as I added the 4th monitor, Xorg dumped core. I
assume that the buffer size of the entire desktop may beyond the GL
surface that my card can handle.

So since then, I have no choice but to stick on the awesome 3.4 version.
I won't blame the upstream for making the decision, because all other
WMs have either already dropped the support for multiple screens or not
implemented it from the beginning. I have used this setup for years and
I don't want to drop my monitors either.

During these years I have met other problems because of the setup. One
particular case is the GTK3 dropped the support for this setup from
3.10.4 [4] and make the X clipboard unusable for years [5] until
recently. I reported these bug to corresponding upstreams and adopt
workarounds myself during these days. Luckily the clipboard issue is
acknowledged by the upstream and its fix has arrived in Arch Linux since
gtk3.18 . There are other small issues that remains or won't fix.

Talk back to awesome 3.4, I maintain this package mainly for my own use,
with the hope that this might help some other people in the same
situation as I am. It can also helps to debug some old devices with
awesome3.4 installed, for example my kindle paperwhite is running Xorg
and awesome3.4 on it, with highly customized lua configuration from amazon.

I hope this can explain my complex feeling about this package.

[1] https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1069
[2] https://wiki.archlinux.org/index.php/Multihead
[3]
https://awesome.naquadah.org/bugs/index.php?do=details&task_id=1069#comment3289
[4] https://bugzilla.gnome.org/show_bug.cgi?id=709716
[5] https://bugzilla.gnome.org/show_bug.cgi?id=719314

--
Jiachen Yang 楊嘉晨
Graduate School of Information Science and Technology, Osaka University
Blog: https://farseerfc.me/
Gmail: farseerfc at gmail.com

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <https://lists.archlinux.org/pipermail/aur-general/attachments/20151106/2b57f2b7/attachment.asc>