From owner-freebsd-multimedia@FreeBSD.ORG Mon Sep 9 20:10:47 2013 Return-Path: Delivered-To: freebsd-multimedia@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTP id 9E3B5844 for ; Mon, 9 Sep 2013 20:10:47 +0000 (UTC) (envelope-from nox@jelal.kn-bremen.de) Received: from smtp.kn-bremen.de (gelbbaer.kn-bremen.de [78.46.108.116]) by mx1.freebsd.org (Postfix) with ESMTP id 222272119 for ; Mon, 9 Sep 2013 20:10:46 +0000 (UTC) Received: by smtp.kn-bremen.de (Postfix, from userid 10) id 901561E007B6; Mon, 9 Sep 2013 22:10:39 +0200 (CEST) Received: from triton8.kn-bremen.de (noident@localhost [127.0.0.1]) by triton8.kn-bremen.de (8.14.5/8.14.4) with ESMTP id r89Jsmh2038935; Mon, 9 Sep 2013 21:54:48 +0200 (CEST) (envelope-from nox@triton8.kn-bremen.de) Received: (from nox@localhost) by triton8.kn-bremen.de (8.14.5/8.14.3/Submit) id r89Jsl0K038934; Mon, 9 Sep 2013 21:54:47 +0200 (CEST) (envelope-from nox) From: Juergen Lock Date: Mon, 9 Sep 2013 21:54:47 +0200 To: Milan Obuch Subject: Re: ITE Technologies, Inc. DVB-T TV Stick, part 2 - remote Message-ID: <20130909195447.GA38609@triton8.kn-bremen.de> References: <20130829214227.3a6b88ab@zeta.dino.sk> <52204121.90301@bitfrost.no> <201309081945.r88Jj9JW076848@triton8.kn-bremen.de> <20130909090439.6fe4869c@zeta.dino.sk> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20130909090439.6fe4869c@zeta.dino.sk> User-Agent: Mutt/1.5.21 (2010-09-15) Cc: freebsd-multimedia@freebsd.org, Juergen Lock X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Sep 2013 20:10:47 -0000 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 wrote: > > > In article <20130830144218.0003446a@zeta.dino.sk> you write: > > >On Fri, 30 Aug 2013 08:52:17 +0200 > > >Hans Petter Selasky 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