Remote control longpress question.

    The cec-client output is pretty much the same. I have emailed Cello in the hope that there is a firmware update.


    For the right button, I get repeats like this (here is prs:10):

    DEBUG: [ 33933] CLinuxCECAdapterCommunication::Process - ioctl CEC_RECEIVE - rx_status=01 len=3 addr=01 opcode=44
    TRAFFIC: [ 33933] >> 01:44:04
    DEBUG: [ 33933] SetCurrentButton right (4) D:0ms cur:17f
    DEBUG: [ 33933] key pressed: right (4) current(4) duration(0)
    DEBUG: [ 33933] key pressed: right (4, 0)
    DEBUG: [ 33933] CheckKeypressTimeout T:51142.040
    DEBUG: [ 33933] Key right: idle (duration:0) (4) timeout:500ms (rel:500,rep:0,prs:10,rel:0)
    DEBUG: [ 33933] >> TV (0) -> Recorder 1 (1): user control pressed (44)

    DEBUG: [ 34264] CLinuxCECAdapterCommunication::Process - ioctl CEC_RECEIVE - rx_status=01 len=2 addr=01 opcode=45
    TRAFFIC: [ 34264] >> 01:45
    DEBUG: [ 34264] key released: right (4) D:3294ms
    DEBUG: [ 34264] >> TV (0) -> Recorder 1 (1): user control release (45)

    For the down button, I get just one:

    DEBUG: [ 36984] CLinuxCECAdapterCommunication::Process - ioctl CEC_RECEIVE - rx_status=01 len=3 addr=01 opcode=44
    TRAFFIC: [ 36984] >> 01:44:02
    DEBUG: [ 36984] SetCurrentButton down (2) D:0ms cur:17f
    DEBUG: [ 36984] key pressed: down (2) current(ff) duration(0)
    DEBUG: [ 36984] Changed key down (2) D:0ms cur:ff
    DEBUG: [ 36984] key pressed: down (2, 0)
    DEBUG: [ 36984] CheckKeypressTimeout T:51145.091
    DEBUG: [ 36984] Key down: idle (duration:0) (2) timeout:500ms (rel:500,rep:0,prs:1,rel:0)
    DEBUG: [ 36984] >> TV (0) -> Recorder 1 (1): user control pressed (44)

    DEBUG: [ 37225] CLinuxCECAdapterCommunication::Process - ioctl CEC_RECEIVE - rx_status=01 len=2 addr=01 opcode=45
    TRAFFIC: [ 37225] >> 01:45
    DEBUG: [ 37226] key released: down (2) D:242ms
    DEBUG: [ 37226] >> TV (0) -> Recorder 1 (1): user control release (45)

    Yes, it's currently not a solution for your situation, but it looks much better. The timeout looks realistic and the different can clearly identified. So it should be technical possible to fix the issue via firmware. I have seen at the Cello webpages, that the remote control has a mouse mode. Does it make a different if you switch on/off this feature after you switched to the HDMI input?

    Just to be sure, since you didn't start with a fresh install. Can you remember if you created an edid.bin file via getedid at some point in the past that might have remained in the directory structure (ls -la /storage/.config/firmware/edid/edid.bin)? If so, remove that via getedid delete and reboot.
    Have you already tried a different HDMI port on your TV?

    I don't think I have the kind of remote that you mention. I don't see any option to enable a mouse mode.

    I don't have a edid.bin file. I don't even seem to have a /firmware directory under /.config .

    I did try another HDMI port quite early on.

    Anyway, I got a reply from their customer support: "We are seeing if we can create some software to change this ramp issue on the navigation keys." However, I don't know what a 'ramp issue' is. Maybe a technical term, or just a spelling mistake? At least they replied.

    Sounds promising. I think they mean some kind of speed ramp (the longer you hold a button down, the shorter the distance to the next repetition) and I'm keeping my fingers crossed.

    PS: Regarding the mouse mode, where I was wrong: As I didn't know the model you have, I chose it at random: 65RTS4K