On Fri, Mar 21, 2014 at 12:27:45AM -0400, Jasper St. Pierre wrote:
So you're saying that every time we're suspended, we simply throw out the
entire context and drop all the devices on the floor, as if you just
unplugged all of them?
No, what I meant was possible was:
1. start
2. resume
Hi
On Fri, Mar 21, 2014 at 6:14 AM, Peter Hutterer
peter.hutte...@who-t.net wrote:
On Fri, Mar 21, 2014 at 12:27:45AM -0400, Jasper St. Pierre wrote:
So you're saying that every time we're suspended, we simply throw out the
entire context and drop all the devices on the floor, as if you just
So you're saying that every time we're suspended, we simply throw out the
entire context and drop all the devices on the floor, as if you just
unplugged all of them?
I suppose I just never thought of that. On first though, I don't see
anything wrong with that.
If that's what we should do, should
On Fri, Mar 21, 2014 at 12:27:45AM -0400, Jasper St. Pierre wrote:
So you're saying that every time we're suspended, we simply throw out the
entire context and drop all the devices on the floor, as if you just
unplugged all of them?
fwiw, this is effectively what happens internally anyway, you
On Sat, Mar 15, 2014 at 07:59:29PM +0100, Jonas Ådahl wrote:
On Thu, Mar 13, 2014 at 04:18:20PM +1000, Peter Hutterer wrote:
When a libinput context for a given seat is initialized, not all devices may
be available. Some or all devices may be paused by systemd-logind. Waiting
for
a
On Thu, Mar 13, 2014 at 04:18:20PM +1000, Peter Hutterer wrote:
When a libinput context for a given seat is initialized, not all devices may
be available. Some or all devices may be paused by systemd-logind. Waiting for
a unplug event is not appropriate here as the devices are physically
When a libinput context for a given seat is initialized, not all devices may
be available. Some or all devices may be paused by systemd-logind. Waiting for
a unplug event is not appropriate here as the devices are physically
available, just prevented from getting access.
Add a
