Hi, just testing:
I get a lot of "DEBUG: cDecoder::GetFrameInfo(): unknown aspect ratio (16:11) at frame xxx
any Idee ?
Greetings Rene
Hi, just testing:
I get a lot of "DEBUG: cDecoder::GetFrameInfo(): unknown aspect ratio (16:11) at frame xxx
any Idee ?
Greetings Rene
In kodi you will not be able to uses the longpress assignments, so less keys (I do not need them )
I believe you also will miss the "increasing scroll speed in long listings".
If my stm is doing a press(KEY_0) wait 20 sec , release
In a linux terminal is see
0, wait 5 seconds, another 0 wait 1 second another 0 etc.. just as expected.
Greetings Rene
Hm,,
ir-keytable -D 5000 -P 1000 -d /dev/input/stm
This is working when looking at evtest output, and in a linux terminal.
It is not working in an X-terminal.
Xorg is creating its own repeats.
Maybe ???
On irmp received non repeat:
save last_received time
send press report
set release_needed
if repeat received
only save last_received time, do not send a hid report
send release report after last_received+ xx ms when needed.
Almost like a real keyboard (but simulating the key-up by timeout)
I think the repeats are handled by the linux kernel, not by sending hid-reports.
>Sonst gibt es manchmal kurzen Nachlauf
Yes if you release a button on a remote it could still send a repeat (100ms ?)
And you need to wait for the release timeout (another 150 ms ?)
In this time the kernel will generate some repeat events.
I do not know how to stop this. (apart from a very low repeat speed)
Hi jrei,
>Dadurch werden aber längere Tastendrücke als mehrere neue Tastendrücke statt als mehrere Wiederholungen gesendet.
>Die Frage ist, ob das irgendwo stört.
Kodi keymap: mod="longpress".
Jörg,
I tried to send a private mail, do not know if it worked.
Greetings René
Hi Jörg,
about repeat: The new version seems to be oke, but maybe the first release will be a bit slower ? (120 vs 30?)
In practise it seems to work oke (tested in vdr).
about usage: With the patch :
I still get one device for our stm32 but with valid fields.
usage-page==FF and usage==1
These values are defined in usb_desc.c (CustomHID_ReportDescriptor), so I think that is correct.
Greetings René
Hi,
250/150 is working perfect for me! That was a quick fix
As for the devices: I only see the hidraw device, not the keyboard.
I also tested "hidusb-dump" and signal11/hidapi : hidtest-hidraw
In hid.c: hid_enumerate there is a
dev_enumerate_add_match_subsystem(enumerate, "hidraw");
doesn't this mean, it will only give me the hidraw devices ???
I also saw an issue about hidapi, that it would skip already open devices. The keyboard is in use (Xorg)
could that be the problem ? (although I tested hidusb-dump without a running X, that was the same.
Greetings René
Hi Jörg,
Is this on linux?
I am testing this on archlinux: if I leave out this test, I only get one device!
the value cur_dev->usage is rubbish, and changing on every scan.
I will test more.
Hi jrie,
I started testing the keyboard version.
So far it is working oke, but I had one problem:
This line "if(cur_dev->usage == 0x00)" in stm32IRconfig_gui.cpp is not working.
I believe the usage field is only valid in MAC and Windows.
But after disabling this line I could configure the keys.
Another problem is the fact that my remote is sending repeats very fast after the initial key press.
So now it is very difficult to send only one KEY, most of the times I get multiple characters.
It would be very nice to have a configurable time between first press and first repeat.
Greetings René (sorry for the English, I can read German, but writing .......)
Hi,
It is now more then 4 weeks ago, that I applied the patch.
Since then no deadlock
N.B. I also have 3 RPI's with mpd as streamdev client, all working as expected.
So fingers crossed.
Greetings Rene
Hi Klaus,
Thanks for looking at this.
I will patch my vdr, and let you know the results.
However that can take a while, my last lock was about 3 weeks ago
Greetings Rene
Hi, after a few weeks I have had the same lock about 3 times.
I still believe it is related to the above.
A little investigation:
Thread one:
cTransfer::~cTransfer transfer.c:22 = cReceiver::Detach();
cReceiver::Detach receiver.c:128 = device->Detach(this);
cDevice::Detach device.c:1822 = camSlot->Assign(NULL); locking cCamslot &mutex !!!!
cCamSlot::Assign ci.c:2162 = assignedDevice->Detach(caPidReceiver)
cDevice::Detach device.c:1807 = Lock()
Thus waiting for device lock
Thread two:
cDevice::Action device.c:1678 = Receiver->Receive(b, TS_SIZE);
This is holding the device lock during "Distribute the packet to all attached receivers:"
cCaPidReceiver::Receive ci.c:217 = AddEmmPid(EmmPid);
cReceiver::AddPid receiver.c:49 = device->AddPid(Pid);
cDevice::AddPid device.c:598 = camSlot->SetPid(Pid, true);
waiting for cCamslot mutex
Greetings Rene
Hi,
I did the same test as before, I now get in the log:
started recdone_thread
2 times : recdone_thread processing filename
ended recdone_thread
So that seems to be oke. I will keep the patch and test further.
Thanks so far.
Rene
Hi,
I get a deadlock in recdone, when two timers stop at the same time!
the vdr watchdog will trigger after 5 minutes with
ERROR: cStateKey::~cStateKey() called without releasing the lock first (tid=0, lock=5 Schedules, key=0x81cb90)
One thread is in recstatus.c line 110
Another thread is in recdoneThread waiting for timer_lock
a gdb bt is attached
Greetings Rene
Hi, I switched to vdr 2.3.8 a week ago.
But unfortunately I have hit a deadlock again possibly related to the above.
I attached a backtrace of the two threads involved
Greetings Rene
Running with this patch for a few days now, so far no problems.
Thanx
Greeting Rene
jrie, Yes thats what I have.
(only Lock if the receiver mutex is free, so a side effect is that we could get
an extra delay here if the other thread is holding the mutex.
Do yo have the black screen on al channels ? or only the encrypted ones ?
I sometimes have a black screen also but only for about 10 seconds !
(missing an ecm ????)
greetings
jrie,
the {] is to put the mutex in a block, at the end of the block the mutexlock will be freeed.
{ //RB prevent deadlock
cMutexLock MutexLock(&mutexReceiver); //RB
Lock();
} //RB