January 2016 - openSUSE GNOME - openSUSE Mailing Lists

Re: [opensuse-gnome] Running Xorg non-root
by Egbert Eich 26 Feb '16

26 Feb '16

Frederic Crozat writes: > Le mercredi 13 janvier 2016 à 11:01 +0100, Egbert Eich a écrit : > > Frederic Crozat writes: > > > Le mardi 12 janvier 2016 à 23:56 +0100, Egbert Eich a écrit : > > > > > > > > > For what it worth, I've been using the xf86-input-libinput on Leap > > 42.1 > > > for several weeks now and it is working great (setup is a > > trackball, a > > > integrated touchpad on Dell laptop and an external touchpad from > > > Logitech, which can do multi-touch..). > > > > > > > I bet it does for you and will do for Stefan, Michal and me as well. > > All of us have a pretty standard setup. We are not using a > > touchscreen > > or any wacom device ;p > > I'm using a wacom device too ;) Ok ;) > > And libinput doesn't try to handle Wacom devices ATM, so it shouldn't > be a problem. Ok. I sort of expected this. The wacom driver is rather ... sophisticated. > > For touchscreen, we'll rely on people to test with hardware, as > always.. Definitely. I need to find time to look into reproducible test procedures - especially for multitouch. Cheers, Egbert.-- To unsubscribe, e-mail: opensuse-gnome+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-gnome+owner(a)opensuse.org

2 1

[opensuse-gnome] adjust timeout for application response
by Olaf Hering 27 Jan '16

27 Jan '16

If some app does not respond within a certain timeframe a popup occours which offers to either kill the app or continue to wait for its response. If an app runs in valgrind or gdb it will react much slower. How can I increase this timeout? Olaf -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-gnome+owner(a)opensuse.org

2 1

[opensuse-gnome] Running Xorg non-root
by Egbert Eich 13 Jan '16

13 Jan '16

Hi Guys, The Gnome team and the team dealing with the hardware pieces of the graphics stack should have a conversation about running X 'non-root'. On openSUSE Tumbleweed gdm is the first DM to run the Xserver without root permissions. An Xserver run as non-root will attempt to acquire permissions for devices from system-logind. Output: ======= Currently, on Tumbleweed, when using 'gdm' as login manager, Xwayland will be started on top of a Wayland Display Server if possible. If the Wayland display server cannot be started, ie. when no suitable driver is around - for instance, when the boot option 'nomodeset' is used, gdm will attempt to start Xorg as user 'gdm'. Once the login succeeds, gdm will start a regular Xserver as the logged in user. At SUSE we still support UMS drivers - including fbdev. In fact, fbdev is part of the fallback strategy we employ: since fbdev uses a VESA mode (which today is set by grub2), this mode will always be available. The UMS driver will fail immediately once the Xserver attempts to load them without root permissions. For the 'fbdev' it depends: this driver only requires access to /dev/fb<N> which allows group access of the 'video' group. Thus the user 'gdm' is able to start it, any other user will fail. This can be fixed by either setting the appropirate file ACLs or using systemd-logind granted access. Setting ACLs for devices is done for DRI devices in /dev/dri/ - it used to be handled by ConsoleKit but is done by uaccess for systemd, today. The bigger challange will be UMS devices. For these the only option I see would be to start them as root or to use a wrapper script to do this (this seems to be the present solution at Debian). The question which remains is, how does GDM know that a wrapper script is required? It would be easy to test for the presence of KMS, however, this will often include cases where fbdev can be used. I'm open to suggestions here ;) - after all, this decision needs to be made in GDM. Input: ====== All evdev input devices are handled by systemd-logind. It remains to check if drivers requiring /dev/input/mouse* or /dev/input/mice need to be equipped with an interface for obtaining the necessary permissions as well. There is one exception among the input drivers: xf86-input-vmmouse. This driver used for guest VMs on VMWare and KVM uses a rather obscure interface - an emulated PIO register. I'm not sure if this device is still supported by KVM, VMWare doesn't strictly require it, however if used, it used to enhance VMWare's capabilities. We may have to drop this driver as I would like to avoid having to use a wrapper for this. So, looking into handling access to /dev/fb<N> and some of the older input devices would be my task. You Gnome folks should consider how to decide when to use a wrapper. For the wrapper code, we should probably cooperate with Debian. Cheers, Egbert. -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-gnome+owner(a)opensuse.org

3 2

Re: [opensuse-gnome] Running Xorg non-root
by Egbert Eich 13 Jan '16

13 Jan '16

Frederic Crozat writes: > Le mardi 12 janvier 2016 à 23:56 +0100, Egbert Eich a écrit : > > The problem with suggests: is that IHMO we have nothing that honors > > them. > > There is no tool that tells you: oh, btw, here are packages that we > > suggest > > should be installed as well. > > Recommends have this weird 'take all or nothing' setting. > > Why not use a Requires for those drivers, on the suid wrapper. > This was my plan. I hope we will have the Recommends:/Suggests: mess resolved soon so that we have tools where users can actually view and (de)select them. > > For what it worth, I've been using the xf86-input-libinput on Leap 42.1 > for several weeks now and it is working great (setup is a trackball, a > integrated touchpad on Dell laptop and an external touchpad from > Logitech, which can do multi-touch..). > I bet it does for you and will do for Stefan, Michal and me as well. All of us have a pretty standard setup. We are not using a touchscreen or any wacom device ;p > > > If the hardware still works, I suppose this is the best we have to > > > offer (at least in openSUSE). From upstream bug, it's being > > suggested > > > that this commit can be reverted for those who want/have to, but > > I'd > > > prefer not to deviate. - I see how you might have different needs > > in > > > SLE though. > > > > We cannot use this on SLE. At least not SLE-12. It is still too > > bleeding > > edge. At least for SP2. > > I guess it will depend how much multitouch we want to support but those > questions are out of topic for this mailing list ;) Right. Hint: there is no 'one thing makes everybody happy'. We may have to offer two solutions. > > > > > > > > Yeah, possibly. I'm not even sure - have we done this on TW > > already? > > > > Last time I've checked we hadn't. > > > > IHMO we should do this there ASAP to have a good test coverage. > > > > > > > > > > Great news :-) as my SR to enable automatic install of xf86-input- > > > libinput a month ago was nacked. I can probably fire up a new one > > some > > > time tomorrow. > > > We did have it as autoinstalled back in March, but at the time, > > neither > > > the driver nor DE's were properly ready for it. Should be quite a > > > different story today (I've been using it on all my boxes since > > > summer). > > > > > I'm not yet sure how to deal with this on Tumbleweed. On one side I > > would like to have this as a test bed for bleeding edge things, on > > the > > other hand I would not want to enforce everything new on everybody. > > Point is: you may want to try out new things in one area to catch > > issues, > > but in other areas you would like to stay more conservative. If you > > have > > too fight too many fires because everything is bleeding edge, you may > > lose interest. I need to think about this some more and certainly > > discussing > > this also helps. > > I guess we'll have do to the jump one day or another (IIRC, Fedora did > the jump on their latest release). Yes, but the developers of most of this are working for RH and RH has simplified things by dropping support for a lot of things altogether which we still support. They never had an fbdev fallback mode AFAIK. > I would do a phased jump: > - do a formal announcement (and even a blog post) on factory mailing > list to ask people using TW to switch their setup to xf86-input > -libinput and report behaviour changes and other bugs. Please make it a special program: tell people what to do to participate in this test endeavor and how to get back if it doesn't work at all. > - ask similar tests on Leap (maybe with some version bump of xf86-input > -libinput and libinput package) Please don't do this on Leap! People there may have a different expectation set. Let's not blur the distinction between Leap and Tumbleweed! > - once dust settles, switch TW to xf86-input-libinput and wait for the > next wave of bug reports and potentially retract the switch, fix stuff > and switch back. I'd rather switch the default once: give people the option to switch before already or switch back after: personal choice - depending on needs. > - switch next Leap to it (and maybe a SLE SP) If things look good, why not? Cheers, Egbert. -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-gnome+owner(a)opensuse.org

3 2

Re: [opensuse-gnome] Running Xorg non-root
by Egbert Eich 13 Jan '16

13 Jan '16

Bjørn Lie writes: > ti., 12.01.2016 kl. 19.29 +0100, skrev Egbert Eich: > > > > We could add a 'recommends:' or 'suggests:' to the affected driver > > packages. Since these packages are only installed if the hardware > > is found, the user will not get the wrapper normally. > > > > I'd have no issues with this. But lets start with a suggests please :-) The problem with suggests: is that IHMO we have nothing that honors them. There is no tool that tells you: oh, btw, here are packages that we suggest should be installed as well. Recommends have this weird 'take all or nothing' setting. > > > > > > > This will hopefully "encourage" upstreams to port their drivers, > > or > > > switch to other ones. > > > > This will not happen. Most of the hardware supported by the UMS > > drivers > > is of marginal relevance today. Therefore the drivers are not really > > supported. Upstream just makes sure they still build. Some community > > users (openSUSE) complain if they don't work as expected in which > > case > > I often reply, that it is a free software project where everybody can > > contribute - if someone is interested in such hardware (s)he should > > expect to have to fix issues her/himself. > > Right, then I have no problem just ignoring those users, as in: We are > sorry, but you will have to use something else than GNOME for this > hardware. Gnome does not support it anymore. Sure, I'm fine with doing this for users who complain about actual bugs. I would like to accomodate those who simply want to use a still working driver at least to some extent. You cannot seriously expect that one of the people already working hard on supporting the current drivers to port S3, Trident, Matrox, SiS or VIA to KMS. > > > > > > > > > Input: > > > > ====== > > > > Yeah, you can. Just not configure them from Gnome. > > Oh have you tested? - that commit is only 8 days old and we do not have > it in GNOME:Next yet. I have not tested, but these drivers will work in X.Org at least. So as long as Gnome supports Xorg, they will continue to work. You will have to do the setup using 'xinput' though. > If the hardware still works, I suppose this is the best we have to > offer (at least in openSUSE). From upstream bug, it's being suggested > that this commit can be reverted for those who want/have to, but I'd > prefer not to deviate. - I see how you might have different needs in > SLE though. We cannot use this on SLE. At least not SLE-12. It is still too bleeding edge. At least for SP2. > > > > Yeah, possibly. I'm not even sure - have we done this on TW already? > > Last time I've checked we hadn't. > > IHMO we should do this there ASAP to have a good test coverage. > > > > Great news :-) as my SR to enable automatic install of xf86-input- > libinput a month ago was nacked. I can probably fire up a new one some > time tomorrow. > We did have it as autoinstalled back in March, but at the time, neither > the driver nor DE's were properly ready for it. Should be quite a > different story today (I've been using it on all my boxes since > summer). > I'm not yet sure how to deal with this on Tumbleweed. On one side I would like to have this as a test bed for bleeding edge things, on the other hand I would not want to enforce everything new on everybody. Point is: you may want to try out new things in one area to catch issues, but in other areas you would like to stay more conservative. If you have too fight too many fires because everything is bleeding edge, you may lose interest. I need to think about this some more and certainly discussing this also helps. Cheers, Egbert. -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-gnome+owner(a)opensuse.org

2 1

Re: [opensuse-gnome] Running Xorg non-root
by Egbert Eich 12 Jan '16

12 Jan '16

Bjørn Lie writes: > ti., 12.01.2016 kl. 13.56 +0100, skrev Egbert Eich: > > > > The bigger challange will be UMS devices. For these the only option I > > see would be to start them as root or to use a wrapper script to do > > this > > (this seems to be the present solution at Debian). > > The question which remains is, how does GDM know that a wrapper > > script > > is required? It would be easy to test for the presence of KMS, > > however, > > this will often include cases where fbdev can be used. I'm open to > > suggestions here ;) - after all, this decision needs to be made in > > GDM. > > For openSUSE I'd be fine with this not being automatic, as in we > provide a suid-wrapper-"compat" package, but do not install it by > default. Those who need it have to install it, and since that will lead > to only users in need, always apply it when installed. We could add a 'recommends:' or 'suggests:' to the affected driver packages. Since these packages are only installed if the hardware is found, the user will not get the wrapper normally. > > This will hopefully "encourage" upstreams to port their drivers, or > switch to other ones. This will not happen. Most of the hardware supported by the UMS drivers is of marginal relevance today. Therefore the drivers are not really supported. Upstream just makes sure they still build. Some community users (openSUSE) complain if they don't work as expected in which case I often reply, that it is a free software project where everybody can contribute - if someone is interested in such hardware (s)he should expect to have to fix issues her/himself. > >From what I understood from a virtualbox bug I was cc'ed on, Oracle is > already underway with theirs. Yeah, this driver is an exception. VMWare and QXL are there already. (Well, VMWare isn't quite: there is still xf86-input-vmware). Cheers, Egbert. > > > > > Input: > > ====== > > For input drivers upstream have already dropped all mouse support for > non-libinput drivers (at least for configuration, I've not verified if > one can still use synaptic/foo but not configure them via gnome-tools) Yeah, you can. Just not configure them from Gnome. > > https://git.gnome.org/browse/gnome-settings-daemon/commit/?id=66c211ff2 > 4bec6a938d6a6a0dd8730f4689ef383 > > > https://bugzilla.gnome.org/show_bug.cgi?id=759595 > > This will kinda force us to Require xf86-input-libinput for the next > release, so I guess that more or less "taken care off" Yeah, possibly. I'm not even sure - have we done this on TW already? Last time I've checked we hadn't. IHMO we should do this there ASAP to have a good test coverage. Cheers, Egbert.-- To unsubscribe, e-mail: opensuse-gnome+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-gnome+owner(a)opensuse.org

2 1

[opensuse-gnome] how to get an up to date GNOME on 13.2
by Mathias Homann 12 Jan '16

12 Jan '16

hi, if I want to run the latest GNOME on 13.2, which repositories do I add? GNOME:Apps, GNOME:STABLE:13.2, or both? cheers MH -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-gnome+owner(a)opensuse.org

2 1

[opensuse-gnome] avoid delay while handling volume keys
by Olaf Hering 11 Jan '16

11 Jan '16

My laptop has keys to adjust the volume for the internal speakers. Some code in the system reacts to these knobs and adjusts the volume. Unfortunatly this code is not instantly available. It has to be loaded from disk, which is slow. A few years ago I wrote a small app which did a mmap of the specified binaries and all its libraries to pin them in memory. As a result the binaries were always responsive. What part of gnome controls the volume keys? Olaf -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-gnome+owner(a)opensuse.org

2 1

[opensuse-gnome] black background with TW20160105
by Olaf Hering 09 Jan '16

09 Jan '16

With current TW the background is black. Is this intentional? I would not mind that much, but my own .desktop files have Icon=computer-symbolic which leads to black-on-black. Olaf -- To unsubscribe, e-mail: opensuse-gnome+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-gnome+owner(a)opensuse.org

5 5