[PATCH libinput] test: call K_OFF when run on the vt

[Peter Hutterer]

On Fri, Apr 06, 2018 at 10:55:59AM +0300, Pekka Paalanen wrote:
> On Fri, 6 Apr 2018 12:31:45 +1000
> Peter Hutterer <peter.hutterer at who-t.net> wrote:
> 
> > On Thu, Apr 05, 2018 at 12:53:45PM +0300, Pekka Paalanen wrote:
> > > On Thu, 5 Apr 2018 15:18:08 +1000
> > > Peter Hutterer <peter.hutterer at who-t.net> wrote:
> > >   
> > > > Slight disadvantage: this breaks Ctrl+C to cancel the test suite when run
> > > > from the VT. Still potentially better than injecting semi-random events.
> > > > 
> > > > Signed-off-by: Peter Hutterer <peter.hutterer at who-t.net>
> > > > ---
> > > > Pekka noticed this yesterday. This approach is the simplest solution,
> > > > allowing the test suite to be run as-is but but as soon as any options are
> > > > specified we don't touch things. This saves us the need for rollbacks in
> > > > case of failures (we usually fork everything except in the below cases).
> > > > 
> > > > It's a bit of a niche case IMO so not sure we need to put a lot more effort
> > > > in. I'm not even that happy with this patch, so unless there's a real need
> > > > for it...
> > > > 
> > > >  test/litest.c | 22 +++++++++++++++++++++-
> > > >  1 file changed, 21 insertions(+), 1 deletion(-)  
> > > 
> > > Hi,
> > > 
> > > Tested-by: Pekka Paalanen <pekka.paalanen at collabora.co.uk>
> > > 
> > > and the code looks reasonable to me, so Reviewed-by as well fwiw.
> 
> > > I'm mostly curious, and I appreciate the right way is to have that Xorg
> > > config snippet in place, so there's no pressing need from my side to
> > > have this patch. However, would you not need this for CI?  
> > 
> > CI is ... tricky. It only works on VMs, not containers, so things like
> > CircleCI only test build combinations. For running the full test suite I
> > don't have automated CI.
> > 
> > Instead, I usually clone into a fresh directory and run my magic script that
> > I've accumulated over the years:
> >     https://gist.github.com/whot/0fa8e0ab40e294b4dbf9d62de97d7794
> > 
> > This usually works fine while you have a normal session going as libinput
> > test devices are ignored by the libinput you have in your compositor.
> > 
> > I also had minimal VMs but on those I usually ran under screen. So running
> > the test suite on the VT is rarely needed.
> 
> Even if you run in screen, aren't the test devices still poking the VT
> console if such exists? Since it is after all adding real-looking
> input devices at the kernel level and those obviously can affect the VT.

maybe, but that doesn't matter when you're ssh-ed in :)
 
> Are you hoping none of the tests happen to produce an input pattern
> that can be executed as a console command or such? :-)

they don't actually. the test suite doesn't send random events. I think F24
is the most risky thing we send, but otherwise you'll end up with a
combination of characters that looks like a dication by a baby after
feeding time.

> Would the patch actually need to always stop current TTY regardless of
> whether the test is actually running on a VT or not?
> 
> Or maybe it's possible to configure the VM or the kernel to not have an
> affected console at all?

I'm not 100% of better solutions for the VT but aiui, as soon as you're under
X/Wayland or ssh'd in or anything, you don't have to care about it. So far,
this has simply been good enough but I'm open for specific ideas - mostly
because I'm on very familiar with the details of handling VTs, TTYs, etc.

I have a dormant patch set that wraps libevdev so that after the initial
setup phase we can swap the fd and the test devices never actually send
events. That could (in theory) take the real-time requirement out of the
test suite too but there's a lot of code that needs to be written, and for
that I need a really good reason.

Cheers,
   Peter