Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 9 Sep 2013 21:54:47 +0200
From:      Juergen Lock <nox@jelal.kn-bremen.de>
To:        Milan Obuch <freebsd-multimedia@dino.sk>
Cc:        freebsd-multimedia@freebsd.org, Juergen Lock <nox@jelal.kn-bremen.de>
Subject:   Re: ITE Technologies, Inc. DVB-T TV Stick, part 2 - remote
Message-ID:  <20130909195447.GA38609@triton8.kn-bremen.de>
In-Reply-To: <20130909090439.6fe4869c@zeta.dino.sk>
References:  <20130829214227.3a6b88ab@zeta.dino.sk> <52204121.90301@bitfrost.no> <201309081945.r88Jj9JW076848@triton8.kn-bremen.de> <20130909090439.6fe4869c@zeta.dino.sk>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Sep 09, 2013 at 09:04:39AM +0200, Milan Obuch wrote:
> On Sun, 8 Sep 2013 21:45:09 +0200 (CEST)
> Juergen Lock <nox@jelal.kn-bremen.de> wrote:
> 
> > In article <20130830144218.0003446a@zeta.dino.sk> you write:
> > >On Fri, 30 Aug 2013 08:52:17 +0200
> > >Hans Petter Selasky <hps@bitfrost.no> wrote:
> > >
> > >> On 08/29/13 21:42, Milan Obuch wrote:
> > >> > Hi,
> > >> >
> > >> > as now I can watch TV with my LV52T stick, I would like to find
> > >> > how to use remote controller. I think this part of stick presents
> > >> > itself as USB HID device, /dev/uhid0 gets created on attachment.
> > >> >
> > >> > As a blind shot I tried
> > >> >
> > >> 
> > >> Hi,
> > >> 
> > >> Usually webcamd will grab the remote part too. Have a look at
> > >> lircd.
> > 
> > See if you get a /dev/input/eventX device node, if yes you can test
> > the remote with:
> > 
> > 	ir-keytable -d /dev/input/event0 -t
> > 
> > (or whatever one you get; ir-keytable belongs to
> > multimedia/v4l-utils.) If it works you can setup lirc, see it's
> > pkg-message.
> >
> 
> When should /dev/input/event0 get created?

By webcamd at the same time as /dev/dvb/adapterX/*.

>  I see no such file on my
> system. When I put LV52T stick in, /dev/ugen4.3 and /dev/uhid0 are
> created (the former is a symlink for /dev/usb/4.3.0), along
> with /dev/usb/4.3.[0-5] files.
> 
> When I kldload cuse4bsd, /dev/cuse gets created.
> 
> When webcamd is running, six moew devices are created,
> /dev/dvb/adapter0/demux0
> /dev/dvb/adapter0/dvr0
> /dev/dvb/adapter0/frontend0
> /dev/dvb/adapter1/demux0
> /dev/dvb/adapter1/dvr0
> /dev/dvb/adapter1/frontend0
> 
> Looking at comms/lirc, it seems like it expects /dev/input/event0
> already existing, so maybe webcamd should create it? If that's true,
> then I need webcamd somehow patched...
> 
 Can you test the remote on a (recent, possible live?) Linux, see
if you get a /dev/input/event node for it there?  Maybe the driver
simply doesn't know about the remote yet...

> > >> Not sure if it supports /dev/uhidX . You could also try uhidd.
> > >> 
> 
> I installed sysutils/uhidd. Now I tried some dump:
> 
> uhidd -D /dev/ugen4.3
> ugen4.3[1]-> Report descriptor dump:
>         USAGE PAGE Generic Desktop(0x1)
>         USAGE Keyboard(0x6)[Generic Desktop(0x1)]
>         COLLECTION Application(1)
>           USAGE PAGE Keyboard(0x7)
>           USAGE MINIMUM Keyboard LeftControl(224)
>           USAGE MAXIMUM Keyboard Right GUI(231)
>           LOGICAL MINIMUM 0
>           LOGICAL MAXIMUM 1
>           REPORT COUNT 8
>           REPORT SIZE 1
>           INPUT ( Data Variable Absolute ) (2)
>           REPORT COUNT 8
>           REPORT SIZE 1
>           INPUT ( Const Array Absolute ) (1)
>           USAGE PAGE LEDs(0x8)
>           USAGE MINIMUM Num Lock(1)
>           USAGE MAXIMUM Scroll Lock(3)
>           REPORT COUNT 3
>           REPORT SIZE 1
>           OUTPUT ( Data Variable Absolute ) (2)
>           REPORT COUNT 1
>           REPORT SIZE 5
>           OUTPUT ( Const Array Absolute ) (1)
>           USAGE PAGE Keyboard(0x7)
>           USAGE MINIMUM Reserved (no event indicated)(0)
>           USAGE MAXIMUM Unknown Usage(255)
>           LOGICAL MINIMUM 0
>           LOGICAL MAXIMUM 255
>           REPORT COUNT 6
>           REPORT SIZE 8
>           INPUT ( Data Array Absolute ) (0)
>         END COLLECTION
> ugen4.3[1]-> Kernel driver is active
> ugen4.3[1]-> Abort attach since kernel driver is active
> ugen4.3[1]-> Please try running uhidd with option '-u' to detach the
> kernel drivers
> 
> Adding -u to flags:
> 
> uhidd -D -u /dev/ugen4.3
> ugen4.3[1]-> Report descriptor dump:
>         USAGE PAGE Generic Desktop(0x1)
>         USAGE Keyboard(0x6)[Generic Desktop(0x1)]
>         COLLECTION Application(1)
>           USAGE PAGE Keyboard(0x7)
>           USAGE MINIMUM Keyboard LeftControl(224)
>           USAGE MAXIMUM Keyboard Right GUI(231)
>           LOGICAL MINIMUM 0
>           LOGICAL MAXIMUM 1
>           REPORT COUNT 8
>           REPORT SIZE 1
>           INPUT ( Data Variable Absolute ) (2)
>           REPORT COUNT 8
>           REPORT SIZE 1
>           INPUT ( Const Array Absolute ) (1)
>           USAGE PAGE LEDs(0x8)
>           USAGE MINIMUM Num Lock(1)
>           USAGE MAXIMUM Scroll Lock(3)
>           REPORT COUNT 3
>           REPORT SIZE 1
>           OUTPUT ( Data Variable Absolute ) (2)
>           REPORT COUNT 1
>           REPORT SIZE 5
>           OUTPUT ( Const Array Absolute ) (1)
>           USAGE PAGE Keyboard(0x7)
>           USAGE MINIMUM Reserved (no event indicated)(0)
>           USAGE MAXIMUM Unknown Usage(255)
>           LOGICAL MINIMUM 0
>           LOGICAL MAXIMUM 255
>           REPORT COUNT 6
>           REPORT SIZE 8
>           INPUT ( Data Array Absolute ) (0)
>         END COLLECTION
> ugen4.3[1]-> Kernel driver is active
> ugen4.3[1]-> kernel driver detached!
> 
> This looks a bit promising, however usbhidd needs a config file to know
> how keys should be handled...
> 
 By the way it's also possible your xserver grabs the uhid node and
any data it receives, you can check that via

	fstat |grep uhid

If that's the issue you could try an xorg.conf with mouse and
keyboard entries and AutoAddDevice set to false... (or first do the
dd test w/o X running.)

 ..and for vdr-plugin-remote at least you don't need uhidd, also see
vdr-plugin-remote's pkg-descr.

> >  I think I played once with an uhid remote and couldn't get repeat
> > to work at least with lirc...  (I then patched the vdr remote plugin
> > for this as vdr handles repeat differently.)
> > 
> > >> dd if=/dev/uhidX bs=1
> > >> 
> > >> --HPS
> > >> 
> > >
> > >I tried dd but nothing happened. Still
> > >
> > >0+0 records in
> > >0+0 records out
> > >0 bytes transferred
> > >
> > >when I press ^T, no matter how many times I press buttons on remote.
> > >
> >  Well then the driver probably didn't setup the uhid part and expects
> > you to use /dev/input instead...  At least I see af9035_rc_query as
> > well as it913x_rc_query in
> > 
> > 	work/webcamd-3.11.0.2/media_tree/drivers/media/usb/dvb-usb-v2/af9035.c
> > 
> > and
> > 
> > 	work/webcamd-3.11.0.2/media_tree/drivers/media/usb/dvb-usb-v2/it913x.c
> > 
> > respectively (not quite sure which one your tuner uses, you could
> > build webcamd with the DEBUG knob enabled and look at the log when
> > starting it manually to find out, and while you're at it also look
> > for logs containing "ir_mode=" and "ir_type=" if its af9035.)
> > 
> > >I think there is something missing or I do not understand it
> > >completely, or both :)
> > >
> >  ..or the Linux code doesn't support your tuner's remote or (kinda
> > less likely) there's still code missing in webcamd.
> > 
> 
> Well, I thing I need somehow analyze USB related part of the game
> unless I find the way to use uhidd... I can try to run usbdump, get some
> info from usbconfig, but presently that's possibly all I can do.
> 
> Milan

 HTH, :)
	Juergen



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