Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 12 Mar 2018 12:12:47 +0100
From:      Bernd Walter <ticso@cicely7.cicely.de>
To:        Hans Petter Selasky <hps@selasky.org>
Cc:        Bernd Walter <ticso@cicely7.cicely.de>, freebsd-arm@freebsd.org, freebsd-current@freebsd.org, ticso@cicely.de
Subject:   Re: webcamd based touchscreen problem on Pi3
Message-ID:  <20180312111246.GA14138@cicely7.cicely.de>
In-Reply-To: <20180310000336.GM86413@cicely7.cicely.de>
References:  <20180308191131.GB86413@cicely7.cicely.de> <20180308200849.GC86413@cicely7.cicely.de> <20180308210805.GE86413@cicely7.cicely.de> <ef53e666-237f-bb96-efaa-d8b9e020488e@selasky.org> <20180309004433.GI86413@cicely7.cicely.de> <4765ef04-6fb1-f9dc-315d-c4419d6ba016@selasky.org> <20180309114025.GJ86413@cicely7.cicely.de> <e7edfe70-d289-da01-c253-01c27febca3b@selasky.org> <20180309132539.GL86413@cicely7.cicely.de> <20180310000336.GM86413@cicely7.cicely.de>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Mar 10, 2018 at 01:03:39AM +0100, Bernd Walter wrote:
> On Fri, Mar 09, 2018 at 02:25:39PM +0100, Bernd Walter wrote:
> > On Fri, Mar 09, 2018 at 01:19:54PM +0100, Hans Petter Selasky wrote:
> > > On 03/09/18 12:40, Bernd Walter wrote:
> > > >Will do the quirk test later.
> > > 
> > > I don't see any stalls during plug-in, so it might be a request webcamd 
> > > issues, which the device doesn't support. Try building webcamd with 
> > > debug support.
> > 
> > It is already build with debug.
> > But I don't see anything of special interest in the output.
> > 
> > [24]sa# webcamd -d ugen0.4
> > Linux video capture interface: v2.00
> > IR NEC protocol handler initialized
> > IR RC5(x/sz) protocol handler initialized
> > IR RC6 protocol handler initialized
> > IR JVC protocol handler initialized
> > IR Sony protocol handler initialized
> > IR SANYO protocol handler initialized
> > IR LIRC bridge handler initialized
> > IR XMP protocol handler initialized
> > b2c2-flexcop: B2C2 FlexcopII/II(b)/III digital TV receiver chip loaded successfully
> > USB Video Class driver (1.1.1)
> > cpia2: V4L-Driver for Vision CPiA2 based cameras v3.0.1
> > pvrusb2: V4L in-tree version:Hauppauge WinTV-PVR-USB2 MPEG2 Encoder/Tuner
> > pvrusb2: Debug mask is 31 (0x1f)
> > USBVision USB Video Device Driver for Linux : 0.9.11
> > Attached to ugen0.4[0]
> > INFO: 0003:0EEF:0005.0001: input: USB HID v1.10 Mouse [BYZHYYZHY By ZH851] on usb-/dev/usb-/dev/usb/input0
> > 
> > DBG: 0003:0EEF:0005.0001: Kicking head 1 tail 0
> > Creating /dev/input/event0
> > 
> > I will redo a test with raspbian.
> > Waveshare delivered a binary kernel (so much about GPL) for their 7" HDMI C
> > until they changed something in the device firmware and upgraded for a newer
> > panel about 2-3 years ago.
> > This is the 10.1" HMDI B and it is a very early version I have, which however
> > should use a firmware similar to the newer 7" HDMI C.
> > I will retest with a stock Raspbian image to be sure I wasn't accidently
> > using a Waveshare image back then.
> > As far as I can see the Linux drivers just quirk the device to the egalaxy
> > driver, so they do know the Waveshare by ID.
> > I couldn't spot a difference between Linux and what is included in the webcamd
> > source.
> 
> So the older 7" HDMI C Rev 1.1 with the non IPS panel won't even attach, but
> it always needed some special binary support for Linux, no surprises here.
> The newer Rev 2.1 with the IPS panel claims to be the same and work with
> webcamd, at least I get data via /dev/input/event0, which looks reasonable
> with evdev-dump.
> That's an interesting starting point.

I've got a new model of the 10" HDMI B.
It behaves differently.
First of all - uep seems to take it, which it didn't for any of
the previous displays I'd tested.
I had to remove the driver from the loader.conf to have webcamd attach to it.
webcamd attaches fine and it delivers touch events:
[29]sa# evdev-dump /dev/input/event0
/dev/input/event0  3041705595.425438 EV_ABS ABS_MT_TRACKING_ID 0x00000000
/dev/input/event0  3041705595.425438 EV_ABS ABS_MT_POSITION_X 0x000001CF
/dev/input/event0  3041705595.425438 EV_ABS ABS_MT_POSITION_Y 0x0000025E
/dev/input/event0  3041705595.425438 EV_ABS ABS_MT_PRESSURE 0x00000005
/dev/input/event0  3041705595.425438 EV_KEY BTN_TOUCH 0x00000001
/dev/input/event0  3041705595.425438 EV_ABS ABS_X 0x000001CF
/dev/input/event0  3041705595.425438 EV_ABS ABS_Y 0x0000025E
/dev/input/event0  3041705595.425438 EV_ABS ABS_PRESSURE 0x00000005
/dev/input/event0  3041705595.425438 EV_SYN SYN_REPORT 0x00000000

Whatever had been the cause for my previous problem, they obviously
have fixed them in firmware.

-- 
B.Walter <bernd@bwct.de> http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180312111246.GA14138>