* Moving the mouse cursor to another screen while scrolling and the Until I stop scrolling and wait for 1-2 additional seconds. (with mouse cursor on the same screen), it continues to stay black * If I continue to use the scroll-wheel while the screen blacked out * Scrolling works fine despite the screen goes black. var/log/syslog, /var/log/Xorg.0.log, nor ~/.xsession-errors when the * I didn't notice any log entries in neither /var/log/kern.log, canĪlso be triggered by scrolling with the mouse wheel. Occassionally happens before the whole screen gets blacks, i.e. * A flickering kind of scrolling of the whole screen contents. The screen is used edgewise): often while typing but sometimes also To dozen seconds in the top left corner (or in the top right corner if * Approximately Application menu sized rectangular flickering every few * Booting into linux-image-4.7.0-1-amd64-unsigned (4.7.4-2).Īdditional, maybe related issues which don't show up with kernel 4.7 (II) modeset(0): Monitor name: SyncMaster (II) modeset(0): Manufacturer: AOC Model: 2269 Serial#: 1527 Port, as well as with an Samsung Full-HD screen connected via
(It happens with both,Īn AOC Full-HD screen bought this year and connected via Display * Changing the monitor or the monitor connector. * Uninstalling or installing i965-va-driver. Version bump in Debian when the issues appeared.
* Downgrading MESA-related packages which approximately had an upstream X session running for about 1 hour now now. Bus 001 Device 004: ID 17ef:6009 Lenovo ThinkPad Keyboard with Happens occassionally, 3 or 4 times in this X session.) * Scrolling in less inside the uxterm with cursor keys or by pressing Seldom enough so that the felt trigger might be a coincidence. * Using the trackpoint on my Lenovo Thinkpad USB Keyboard. X session, but then again I needed to switch desktops rather seldom * Switching i3's currently displayed desktop using keybindings (e.g. Scroll-wheel triggers the issue again if it happens within a dozen ofīut there are also other things which can trigger it. If it has been triggered once, _every_, even the slowest move of the Scrolling quickly initially seems to trigger the issue more often, but I can't do any serious work while running under 4.8rc5 withoutĬoncentrating a lot on not using the scroll-wheel.
Nevertheless it happens often enough to be very annoying and That's how I can reproduce it very quickly despite notĪlways. In case of multiple screens, only the one on which the mouse cursor Mouse causes the same issues, at least in Emacs. Scrolling sidewards inside Emacs using the tiltable scrollwheel of my uxterm, emacs24-lucid, liferea orĬonkeror, sometimes even on the desktop background), the screen getsĬompletely black for 1-2 seconds and then everything is back to normal. If I use my mouse's scroll wheel on an application which supports
#UXTERM TRIED TO USE LOCALE I3 PC#
Is easily reproducible for me on my desktop PC running Debian Unstable: When running under kernel 4.8rc5, the following (rather annoying) issue I'm still working out some kinks, which I'm documenting there.Date: Sat, 21:26:42 +0200 Package: src:linux Xephyr -br -ac -noreset -screen 2400x1600 -dpi 234 -resizeable -noreset :2 &Įdit: threw the dotfiles into a Github repo. This is my startup script for it all: #!/bin/bash You need to exit i3 directly ( Alt+Shift+E). Xephyr ignores the window close event (from clicking the X in the window titlebar). Some sort of clipboard syncing solution is needed to keep the Chrome OS clipboard ( :0) in sync with the Xephyr one ( :2). Xephyr (or Chrome OS?) mangles Alt+Shift+Up into Prior and Alt+Shift+Down to Next, requiring some remapping. You need to unset XDG_RUNTIME_DIR to stop that behaviour. Sommelier gets in the way of starting applications within Xephyr (it MITMs their X commands and displays forwards them to Chrome OS' XWayland, regardless of the value of DISPLAY). There's a bunch of kind of non-obvious things that need to be dealt with to get stuff working: Polybar and my background need an i3 reload ( Alt+Shift+R) to reposition themselves, but that's quick enough. It works pretty well (no noticeable lag typing in uxterm within i3/Xephyr versus Alacritty outside), and i3 handles resize events smoothly. I like Chrome OS for travel, but dislike the (lack of) keybindings, so this was my solution: i3 running in Xephyr on my Chrome OS 79 Pixelbook. Posting since I haven't seen any posts about this before, and thought it might be cool for some.
0 kommentar(er)
