Beiträge von rvdb

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