[00:01] ali1234: I don't suppose you know of min/max mouse acceleration options with xorg? Can't seem to find any docs on it. Related to https://bugzilla.xfce.org/show_bug.cgi?id=12622 [00:01] Xfce bug 12622 in Xfce4-settings "mouse acceleration capped at 10" [Normal, Assigned] [03:41] i don't know but the acceleration slider in mouse settings seems to have no effect for me [09:53] ali1234: that's seemingly related to libinput [10:06] bluesabre: having it built with libinput support in some ppa would help to test it === ondondil_ is now known as ondondil [11:22] This week I discovered a security vulnerability in the screen-lock/hide desktop functionality. When there are multiple X screens the lock only operates on :0.0. Contents of other X screens remain visible. This reminded me of the same bug I reported in 2013 (!) in KDE which has still not been fixed. Where best to report this against? Presumably upstream but not sure which project/package. ( Bug #1264821 [11:22] Bug 1264821 in kde-workspace (Ubuntu) "kscreenlock_greet insecure with multiple X screens" [Medium, In Progress] https://launchpad.net/bugs/1264821 [11:22] ) [11:40] TJ-: light-locker would be the project I believe, https://github.com/the-cavalry/light-locker would be the upstream [11:42] (fairly dormant upstream, tbh) [11:44] hmmm, it looks like it should just be dropped! combined with the other LL bug where lid-induced suspend results in 'dead' tty on resume! [11:45] It really annoys me, devs working on core display technology don't test on multiple X screens - which is a very common scenario in enterprises especially. [11:55] I'll look at it in more depth next week [11:56] I've considered in the past porting gnome-screensaver to xfce [11:56] works well as a lock screen, and switch user works [11:57] not tried with multiple X screens, but likely has better support than light-locker [11:57] even though ll was originally based on it [12:06] you can simply go to one of the first revisions when i was still contributing a bit more [12:06] that's basically gnome-screensaver without gnome depends [12:06] (and that was my original idea) [12:08] neat [12:08] it was usable and working [18:26] bluesabre: I'm curious about this one also https://git.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/xfce4-settings&id=a1a6ca07f0577a62b8e6679ee023eea774502d8e [18:27] this was linked in a launchpad report [18:28] what would not building with upower support break? [18:32] xubuntu users often mention the workaround to edit /etc/UPower/UPower.conf, and do IgnoreLid=false ==> IgnoreLid=true [18:32] as workaround for that black screen thing [18:38] brainwash: I don't know the answer to that. As far as I know, some laptops report to Upower one value, while others do the reverse [18:38] ochosi may know more [18:39] the archlinux people do not seem to have any major problems with their builds [18:40] at least they did not revert that linked commit [18:41] I'd think that systemd can handle those events [18:41] lid close/open [18:41] interesting; that's the bug I originally reported. Not revisited it since, I just manually suspend before closing the lid [18:42] you mean bug 1431149 ? [18:42] Bug 1431149 in xfce4-settings (Ubuntu) "XFCE 4.12 Black screen after wakeup from suspending by closing the laptop lid" [Undecided, Confirmed] https://launchpad.net/bugs/1431149 [18:42] Bug #1759950 [18:42] Bug 1759950 in light-locker (Ubuntu) "Lid-close suspend: blank screen when switching to user session" [Undecided, New] https://launchpad.net/bugs/1759950 [18:43] still open [18:43] upstream I mean [18:44] light-locker upstream is basically abandonware so far as I could tell [18:44] it does look like it [18:45] I did a lot of source-code diving/debugging and narrowed it down some, but never got to looking at upower. If I can find some time this week I'll investigate that lead and report back in my bug report [18:45] I recall that getting rid of VT switching was on the roadmap [18:45] sadly, no progress [18:47] what I found was that in the LidClose event case, the number of Close events didn't match the number of Open events after resume, which seemed to leave the X server state as DPMS off or something. My memory is quite sketchy without re-reading my notes [18:47] is that with xubuntu only? [18:48] yes [18:48] I also noticed it seems to be timing related, in that for me at least, faster CPUs seemed to suffer it more than slower ones. Not sure if that was just co-incidence though - I didn't do rigorous tests of that! [18:49] maybe building -settings without upower could somehow help [18:50] I assume that would mean that upower is not pulled in anymore [18:50] wait. the power-manager needs it still, or? [18:51] this really requires a proper investigation =S [18:54] looking at the source, it provides a dbus service for x-p-m [19:01] ah [19:02] does x-p-m really need that service? [19:02] I assume that it can fall back to systemd [19:03] I've just spotted a bug in upower, reporting the battery state as 208% of design capacity [19:03] that's called 'supercharged' [19:05] note line 45 vs line 5: http://paste.ubuntu.com/p/bphCcjmFbd/ [19:12] on 18.10 I have problems with whoopsie - https://ibb.co/jYT0ue [19:14] I think it's when I want to report that "once a day" bug with cups-browsed [19:20] < bluesabre> works well as a lock screen, and switch user works I think you just described xscreensaver? :P [19:20] Unit193: didn't you share that xscreensaver sometimes doesn't show for folks now :D [19:22] Oooh dang, you do read me. :3 And yeah, login screen tends to flash for a second then goes away, but esc out of it and move mouse again to bring it up. [19:22] And only Xfce folks! :P [19:23] Unit193's new motto: "Use GNOME, people!" [19:23] my new motto: Use knome, people!" [19:23] uhhh [19:23] :D [19:23] Pretty sure that'd be the last thing I'd say. [19:23] :D [19:23] i'm sure you didn't intend it to be interpreted as i did.. [19:24] probably not [19:24] (: [19:55] Besides, there's Xfce people here, that might be an Xfce specific problem, maybe one of them can fix it! :D [20:02] :D