Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

x/exp/shiny: key repeats reported as release + press #18566

Open
barnex opened this issue Jan 8, 2017 · 3 comments
Open

x/exp/shiny: key repeats reported as release + press #18566

barnex opened this issue Jan 8, 2017 · 3 comments
Labels
NeedsFix The path to resolution is known, but the work has not been done.
Milestone

Comments

@barnex
Copy link

barnex commented Jan 8, 2017

What did you do?

This program opens an x/exp/shiny window and reports key presses:

package main

import (
    "log"
    "golang.org/x/exp/shiny/driver"
    "golang.org/x/exp/shiny/screen"
    "golang.org/x/mobile/event/key"
)

func main() {
    log.SetFlags(log.Lmicroseconds)
    driver.Main(func(s screen.Screen) {
        w, _ := s.NewWindow(nil)
        for {
            e := w.NextEvent()
            if e, ok := e.(key.Event); ok {
                log.Println(e.Direction)
            }
        }
    })
}

What did you expect to see?

According to https://github.com/golang/mobile/blob/master/event/key/key.go#L50, key repeats should report key.DirNone. So when pressing and holding down a key for a while, I expect to see:

11:59:49.544507 Press
11:59:50.045002 None
11:59:50.076717 None
11:59:50.107537 None
11:59:50.137585 Release

What did you see instead?

Holding down a key results in repeated Release/Press events:

11:59:49.544507 Press
11:59:50.045002 Release
11:59:50.045110 Press
11:59:50.076717 Release
11:59:50.076807 Press
11:59:50.107537 Release
11:59:50.107578 Press
11:59:50.137585 Release

What version of Go are you using (go version)?

go version go1.7.1 linux/amd64

What operating system and processor architecture are you using (go env)?

GOARCH="amd64"
GOBIN=""
GOEXE=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/arne"
GORACE=""
GOROOT="/home/arne/bin/go"
GOTOOLDIR="/home/arne/bin/go/pkg/tool/linux_amd64"
CC="gcc"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build871086202=/tmp/go-build -gno-record-gcc-switches"
CXX="g++"
CGO_ENABLED="1"
@as
Copy link
Contributor

as commented Jan 8, 2017

I wasn't able to reproduce this on NT, so I looked to Linux as the culprit.

According to xorg

The X server usually generates both press and release events whenever an autorepeating key is held down. If an XKB-aware client enables the DetectableAutorepeat per-client option for a keyboard, the server sends that client a key release event only when the key is physically released. For example, holding down a key to generate three characters without detectable autorepeat yields:

Press -> Release -> Press -> Release -> Press -> Release
If detectable autorepeat is enabled, the client instead receives:

Press-> Press -> Press -> Release
Note that only clients that request detectable autorepeat are affected; other clients continue to receive both press and release events for autorepeating keys. Also note that support for detectable autorepeat is optional; servers are not required to support detectable autorepeat, but they must correctly report whether or not it is supported.

@titanous titanous changed the title exp/shiny: key repeats reported as release + press x/exp/shiny: key repeats reported as release + press Jan 9, 2017
@titanous titanous added this to the Unreleased milestone Jan 9, 2017
@titanous
Copy link
Member

titanous commented Jan 9, 2017

/cc @nigeltao

@nigeltao
Copy link
Contributor

nigeltao commented Jan 12, 2017

Yeah, it's a bug in the x11driver, although if fixing this involves XKB's DetectableAutorepeat, as @as suggested, then it's not going to be trivial. The xgb library that we use says, in https://github.com/BurntSushi/xgb/blob/master/doc.go: "XKB is the only extension that intentionally does not work... due to its complexity and my current mental incapacity to test it."

@nigeltao nigeltao self-assigned this Jan 12, 2017
@ALTree ALTree added the NeedsFix The path to resolution is known, but the work has not been done. label Sep 22, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
NeedsFix The path to resolution is known, but the work has not been done.
Projects
None yet
Development

No branches or pull requests

5 participants