NetBSD Problem Report #51149

From rhialto@falu.nl  Tue May 17 20:25:08 2016
Return-Path: <rhialto@falu.nl>
Received: from mail.netbsd.org (mail.netbsd.org [199.233.217.200])
	(using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
	(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (verified OK))
	by mollari.NetBSD.org (Postfix) with ESMTPS id DD6227A3D6
	for <gnats-bugs@gnats.NetBSD.org>; Tue, 17 May 2016 20:25:08 +0000 (UTC)
Message-Id: <201605172025.u4HKP1NT007760@murthe.falu.nl>
Date: Tue, 17 May 2016 22:25:01 +0200 (CEST)
From: rhialto@falu.nl
Reply-To: rhialto@falu.nl
To: gnats-bugs@NetBSD.org
Cc: rhialto@falu.nl
Subject: Mouse problems tickled by gtk3 with some graphics hardware
X-Send-Pr-Version: 3.95

>Number:         51149
>Category:       pkg
>Synopsis:       Mouse problems tickled by gtk3 with some graphics hardware
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    pkg-manager
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Tue May 17 20:30:00 +0000 2016
>Originator:     Rhialto
>Release:        NetBSD 7.0
>Organization:

>Environment:


System: NetBSD murthe.falu.nl 7.0 NetBSD 7.0 (GENERIC.201509250726Z) amd64
Architecture: x86_64
Machine: amd64
>Description:
	I know it sounds idiotic, but from the available evidence I
	can't really draw another conclusion.

	This is what I see:

	In editors/abiword, net/transmission-gtk, and net/wireshark I
	see similar mouse problems. These are all gtk3 programs. I only
	see the problems on my floortop-cum-server, not on my laptop.
	Both computers have identical software versions installed (not
	all the same packages on both, though) self-built from
	pkgsrc-2016Q1. The hardware, and in particular graphics
	hardware, differs. The laptiop has Intel graphics (i915), the
	floortop has Radeon.

	The problems are as follows. Clicking on a GUI element in a
	window of the mentioned programs works only once or a very few
	times. After that, clicks are ignored, and hovering over buttons
	also has no feedback effect (when it should have).

	In Abiword, clicking on text to place the caret makes the other
	GUI elements insensitive, and drag-selecting doesn't work. I
	also saw this in a text field in transmission-gtk. (There is one
	when creating a new torrent.)

	Tabs (to select different tabbed panes) sometimes highlight when
	hovered over even if they don't work when clicked.

	In some cases (but not all; wireshark seems extra-stubborn)
	switching to another workspace (with ctwm) and back temporarly
	"fixes" the problem. Iconify and de-iconify may also work (but
	in fewer cases).

	In transmission-gtk, I see sometimes that if I click on
	something, the focus still seems to be with the last thing that
	I clicked successfully, and it clicks that button again (even
	though the mouse is somewhere totally different).

	Possibly related is Calibre: although this is a Qt5 program, it
	also shows different mouse behaviour on the floortop. If I click
	once on some text in the ebook-viewer or the ebook-editor, it
	selects the whole paragraph (this normally requires a
	triple-click). Also, when starting up (locally), it complains:
	libGL error: unable to load driver: r600_dri.so
	libGL error: driver pointer missing
	libGL error: failed to load driver: r600
	libGL error: unable to load driver: swrast_dri.so
	libGL error: failed to load driver: swrast

	It seems to be the display server that makes the difference:
	running on the laptop with the floortop as display is broken.
	But when running Abiword remotely, displaying on the laptop, it
	complains:
	libGL error: failed to authenticate magic 89
	libGL error: failed to load driver: i965
	libGL error: unable to load driver: swrast_dri.so
	libGL error: failed to load driver: swrast
	but still seems to work. (i965 would be the hardware of the
	display).

	Especially given the data point regarding Calibre, the only real
	difference I see between working and non-working is the
	graphical hardware.  But I can't myself really believe that
	*output* peripherals would have an influence to break a very
	different *input* peripheral.

	Working graphics on laptop:

	agp0 at pchb0: G4X-family chipset
	agp0: detected 65020k stolen memory
	agp0: aperture at 0xc0000000, size 0x10000000
	i915drmkms0 at pci0 dev 2 function 0: vendor 0x8086 product
	0x2a42 (rev. 0x07)
	drm: Memory usable by graphics device = 512M
	drm: Supports vblank timestamp caching Rev 2 (21.10.2013).
	drm: Driver supports precise vblank timestamp query.
	i915drmkms0: interrupting at ioapic0 pin 16 (i915)
	intelfb0 at i915drmkms0
	i915drmkms0: info: registered panic notifier
	intelfb0: framebuffer at 0xffff8000470a3000, size 1600x900,
	depth 32, stride 6400
	wsdisplay0 at intelfb0 kbdmux 1: console (default, vt100
	emulation), using wskbd0
	wsmux1: connecting to wsdisplay0
	vendor 0x8086 product 0x2a43 (miscellaneous display, revision
	0x07) at pci0 dev 2 function 1 not configured

	Broken graphics on floortop:

	drm: initializing kernel modesetting (CEDAR 0x1002:0x68F9
	0x1043:0x03CA).
	drm: register mmio base: 0xf7e20000
	drm: register mmio size: 131072
	drm kern info: ATOM BIOS: 68F9.12.20.0.60.AS01
	radeon0: info: VRAM: 1024M 0x0000000000000000 -
	0x000000003FFFFFFF (1024M used)
	radeon0: info: GTT: 1024M 0x0000000040000000 -
	0x000000007FFFFFFF
	drm: Detected VRAM RAM=400M, BAR=256M
	drm: RAM width 64bits DDR
	Zone  kernel: Available graphics memory: 11576082 kiB
	Zone   dma32: Available graphics memory: 2097152 kiB
	drm: radeon: 1024M of VRAM memory ready
	drm: radeon: 1024M of GTT memory ready.
	drm: Loading CEDAR Microcode
	drm: Internal thermal controller without fan control
	drm: radeon: dpm initialized
	drm: GART: num cpu pages 262144, num gpu pages 262144
	drm: PCIE GART of 1024M enabled (table at 0x000000000025D000).
	radeon0: info: WB enabled
	radeon0: info: fence driver on ring 0 use gpu addr
	0x0000000040000c00 and cpu addr 0x0xffff80023b740c00
	radeon0: info: fence driver on ring 3 use gpu addr
	0x0000000040000c0c and cpu addr 0x0xffff80023b740c0c
	radeon0: info: fence driver on ring 5 use gpu addr
	0x000000000005c418 and cpu addr 0x0xffff80023b33e418
	drm: Supports vblank timestamp caching Rev 2 (21.10.2013).
	drm: Driver supports precise vblank timestamp query.
	radeon0: interrupting at ioapic0 pin 16 (radeon)
	drm: radeon: irq initialized.
	drm: ring test on 0 succeeded in 1 usecs
	drm: ring test on 3 succeeded in 1 usecs
	drm: ring test on 5 succeeded in 1 usecs
	drm: UVD initialized successfully.
	drm: ib test on ring 0 succeeded in 0 usecs
	drm: ib test on ring 3 succeeded in 0 usecs
	drm: ib test on ring 5 succeeded
	drm: Radeon Display Connectors
	drm: Connector 0:
	drm:   HDMI-A-1
	drm:   HPD1
	drm:   DDC: 0x6460 0x6460 0x6464 0x6464 0x6468 0x6468 0x646c
	0x646c
	drm:   Encoders:
	drm:     DFP1: INTERNAL_UNIPHY1
	drm: Connector 1:
	drm:   DVI-I-1
	drm:   HPD4
	drm:   DDC: 0x6450 0x6450 0x6454 0x6454 0x6458 0x6458 0x645c
	0x645c
	drm:   Encoders:
	drm:     DFP2: INTERNAL_UNIPHY
	drm:     CRT2: INTERNAL_KLDSCP_DAC2
	drm: Connector 2:
	drm:   VGA-1
	drm:   DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c
	0x643c
	drm:   Encoders:
	drm:     CRT1: INTERNAL_KLDSCP_DAC1
	radeondrmkmsfb0 at radeon0
	radeon0: info: registered panic notifier
	radeondrmkmsfb0: framebuffer at 0xffff80023b962000, size
	1920x1200, depth 32, stride 7680
	wsdisplay0 at radeondrmkmsfb0 kbdmux 1: console (default, vt100
	emulation), using wskbd0
	wsmux1: connecting to wsdisplay0

>How-To-Repeat:
	See above.
>Fix:
	None known..

	This is a sort-of continuation of PR pkg/50320, which can be
	closed.

-Olaf.
-- 
___ Olaf 'Rhialto' Seibert  -- The Doctor: No, 'eureka' is Greek for
\X/ rhialto/at/xs4all.nl    -- 'this bath is too hot.'

>Unformatted:

NetBSD Home
NetBSD PR Database Search

(Contact us) $NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2014 The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.