Hi Yves-Alexis,
This is just to let you know that the workaround reported by John Franklin on
22 June works for me too.
That is, since adding this *.conf file, I haven't seen the buggy behaviour
anymore:
/etc/X11/xorg.conf.d/20-intel.conf
Section "Device"
Identifier "Intel Graphics"
Dri
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Mon, 2019-07-01 at 14:13 -0500, Michael Umland wrote:
> I do not think this particular bug is dependent on any one driver (Intel or
> otherwise) as previous posters have suggested. I have also experienced this
> bug on a fresh installation using a
I do not think this particular bug is dependent on any one driver (Intel or
otherwise) as previous posters have suggested. I have also experienced this
bug on a fresh installation using a Radeon 580 and the open-source amdgpu
driver.
I was able to work around the problem temporarily by changing th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
Control: forcemerge -1 868087
On Thu, 2019-06-27 at 12:02 -0400, Onyuksel, Cem wrote:
> I'd like to point out that this bug has a similar effect on nvidia graphics
> as well, as pointed out in the bug report
> https://bugs.debian.org/cgi-bin/bugrepo
I'd like to point out that this bug has a similar effect on nvidia graphics
as well, as pointed out in the bug report
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=868087
And their solution was also to generate an xorg.conf file, so I'd guess
it's the same bug.
- Cem
On Tue, 25 Jun 2019 09:3
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
control: affects -1 xserver-xorg-core
On Sat, 2019-06-22 at 17:34 -0400, John Franklin wrote:
> I've been suffering from this bug in a clean Buster system, too. A
> solution noted in another bug tracker is to explicitly tell X.org to
> use the inte
Am 22.06.19 um 23:34 schrieb John Franklin:
>
> I've been suffering from this bug in a clean Buster system, too. A
> solution noted in another bug tracker is to explicitly tell X.org to
> use the intel driver. Apparently, it uses the fbdev driver by default.
> (Sorry, I don't have a reference to
On Sat, 1 Jun 2019 06:16:58 +0530 Raj Kiran Grandhi <
grajki...@gmail.com> wrote:
> Hi,
>
> In a fresh install of Buster with XFCE desktop, locking the screen
> blanks the monitor and the monitor enters a power save state. After
> that, neither moving the mouse nor typing on the keyboard would tur
On Tue, Jun 4, 2019 at 4:12 AM Yves-Alexis Perez wrote:
> My gut feeling is that light-locker just uses codepaths not really used
> otherwise, like vt-switch at the same time as suspend/resume or screen off/on.
> Unfortunately debugging i915 is completely out of my league (and I already
> tried mu
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Mon, 2019-06-03 at 12:59 -0700, Russ Allbery wrote:
> Ah, good call. I was also seeing other problems with the Intel driver in
> combination with light-locker where the monitor resolution would be set to
> some incorrect value after restore from
Yves-Alexis Perez writes:
> Actually it seems to me that the bug is a bad interaction with light-
> locker/lightdm locking system (which relies on vt switch) and the Intel
> driver. It only seems to happens on this driver, and I think it's also
> been reproduced just by doing vt-switches (but can
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Mon, 2019-06-03 at 21:55 +0200, Yves-Alexis Perez wrote:
> I noted Andreas raised the severity, but I hope someone has an idea how to fix
> that because I don't.
Also, since it was posted on -devel, I guess there's a bit of exposure: if
some peop
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Fri, 2019-05-31 at 18:32 -0700, Russ Allbery wrote:
> This appears to be a bug in light-locker specifically, which is the
> default screen lock program with XFCE with lightdm. See, for instance:
>
> https://github.com/the-cavalry/light-locker/is
(This probably belonged on debian-user, but since I have background on
this specific problem and already did the research.)
Raj Kiran Grandhi writes:
> In a fresh install of Buster with XFCE desktop, locking the screen
> blanks the monitor and the monitor enters a power save state. After
> that,
Hi,
In a fresh install of Buster with XFCE desktop, locking the screen
blanks the monitor and the monitor enters a power save state. After
that, neither moving the mouse nor typing on the keyboard would turn
the monitor back on.
I could find two ways to get the display back on:
1. Typing the pass
On Sat, Jun 01, 2019 at 11:06:42AM +0200, Andreas Tille wrote:
> > This appears to be a bug in light-locker specifically, which is the
> > default screen lock program with XFCE with lightdm. See, for instance:
> >
> > https://github.com/the-cavalry/light-locker/issues/114
> >
> > Switching to an
Hey Adam
On 2019/06/01 18:29, Adam Borowski wrote:
> At the time of the xscreensaver debacle, there was no sane alternative
> (candidates depended on 80% of GNOME, offered no feedback nor discoverable
> controls to the user, etc). There _is_ a wonderful alternative now:
> xfce4-screensaver, which
On Sat, Jun 01, 2019 at 06:29:31PM +0200, Adam Borowski wrote:
> Using unstable myself, I'm not sure what to recommend for Buster.
https://tracker.debian.org/pkg/physlock
signature.asc
Description: PGP signature
Adam Borowski writes:
> But, the culprit is light-locker. In general, it's in such a buggy
> state that I believe it shouldn't be in the distribution at all, much
> less a default of any kind. After it replaced xscreensaver[1] as the
> xfce's dependency, I went into some pretty heated arguments
On Sat, Jun 01, 2019 at 06:16:58AM +0530, Raj Kiran Grandhi wrote:
>
> In a fresh install of Buster with XFCE desktop, locking the screen
> blanks the monitor and the monitor enters a power save state. After
> that, neither moving the mouse nor typing on the keyboard would turn
> the monitor back
Georg Faerber writes:
> On 19-06-01 11:04:28, Russ Allbery wrote:
>> I did some research on that a while back and ended up not filing a bug
>> about it because it looked relatively pointless. It appeared to be a
>> deep design choice on both sides, and not something anyone was likely
>> to solve
21 matches
Mail list logo
