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@gmail.com

On 11/10/2015 03:39 PM, Felix Yan wrote:

On 11/05/2015 06:16 PM, Jiachen Yang wrote:

...

Hi everyone,

I (nickname farseerfc) would like to apply as a Trusted User. Felix Yan (felixonmars) will be my sponsor. [...]

Discussion period has ended. You can now cast your votes [1]. The voting period ends on 2015-11-17.

https://aur.archlinux.org/tu/?id=84

Hi Jiachen, great to hear that Felix has found someone that he has searched for a very long time :-) The following list seems long, but its just very minor nitpicking... don't be scared please! :) Sorry that I post some minor nitpicking after the discussion period has ended... I forgot my mail in my drafts folder. I will do my vote either way, but just wanted to provide my collected information to you so its not worthless :-) 1) some packages should include a unique source file prefix if they were pulled from f.e. github and only contain the $pkgver as tarball: - cutegram - libqtelegram-ae - telegramqml - powder-toy - wecase 2) VCS packages (like git) should add provides and conflicts of the providing name (that does not include the VCS postfix) - cutegram-git - notify-desktop-git 3) external references variables should be used only inside of quotation-marks - ipad_charge 4) You could use the new fancy VCS style for jfbpdf, it also should either have a -git suffix or be pinned to a static commit - jfbpdf 5) there is no need anymore for ' || return 1' in normal commands - cdate 6) a concrete (old) version package should always provide and conflict the one it overrides: - awesome34 cheers, Levente