Logitech Dinovo Edge Bluetooth keyboard no longer working after update to 11.95.1

    • New
    Quote from mglae

    Change download source:

    Applied the patch locally. Build is running without errors for now. Thanks!

    • New

    OK, I have a working image. It took a while because my hardware is a bit oldish and the virtual machine on which I created the image was running on 50% of the total resources :)

    • New

    Now you have a working image we need to rebuild/test with different BlueZ versions. To guide the process we will download sources for BlueZ and start a "bisect" process in the BlueZ source directory by marking known-good (v5.72) and known-bad (v5.73) release commits (using the commit githashes):

    Code
    cd ~/
git clone https://github.com/bluez/bluez
cd bluez
git bisect good 770ad5614e7e8074133e6f563495ce4822f63fe4
git bisect bad 19f8fcdc2084048bebe5bd9ea4fb97f7ece16df0
git bisect start

    Bisect will now suggest a githash to test. Change to the LE buildsystem (open another tab in Terminal to make copy/pasting easier) and edit packages/network/bluez/package.mk and make changes:

    ^ We change PKG_VERSION to use whatever githash bisect is asking to test (change this each time). We also null PKG_SHA256 so it is ignored (to make testing easier). We also change PKG_URL to download from the BlueZ mirror on GitHub instead of the normal repo as this supports downloading at any githash in the repo (the kernel repo only has release versions).

    Once package.mk is modified, run the "PROJECT=xxx ARCH=xxx" image build command again and the buildsystem will detect the BlueZ package changed and it will rebuild that package and create a new image. You can then transfer (e.g. scp) the built image (.img.gz or .tar file) to /storage/.update/ on your test device and reboot to see if the image works?

    If the image is good run "git bisect good" in the BlueZ source dir, and if bad run "git bisect bad" and bisect will suggest another githash to test. Keep repeating this process (edit githash, rebuild, test, mark good/bad) until bisect tells you the first bad (breaking) commit. Then report back here with that info.

    Good luck :)

    • New

    Ok, thanks for the info. It will take some time though :) Will report back when I find the first breaking commit.

    Quote from chewitt

    Once package.mk is modified, run the "PROJECT=xxx ARCH=xxx" image build command again and the buildsystem will detect the BlueZ package changed and it will rebuild that package and create a new image. You can then transfer (e.g. scp) the built image (.img.gz or .tar file) to /storage/.update/ on your test device and reboot to see if the image works?

    In stead of "updating" my current system I suppose I can also create a USB stick with the first bisected image on it and run it with the "run" option once and after that copy the next image to /storage/.update/ on the USB stick and run it and apply the "update".

    Edited once, last by ehoitinga: Merged a post created by ehoitinga into this post. (April 22, 2024 at 7:38 PM).

    • New
    Quote from ehoitinga

    In stead of "updating" my current system I suppose I can also create a USB stick with the first bisected image on it and run it with the "run" option once and after that copy the next image to /storage/.update/ on the USB stick and run it and apply the "update".

    Sure, we'll end up with the same result :thumbup:

    • New

    With using the USB stick you can even avoid the reboot when updating by replacing both KERNEL and SYSTEM with the new generated *.kernel and *.system files.

    • New

    The git bisect good command asks me to first do git bisect start:

    Code
    erik@ubuntu-libreelec:~/bluez$ git bisect good 770ad5614e7e8074133e6f563495ce4822f63fe4
You need to start by "git bisect start"

Do you want me to do it for you [Y/n]?

    Should the order of the commands be:

    Code
    git bisect start
git bisect good 770ad5614e7e8074133e6f563495ce4822f63fe4
git bisect bad 19f8fcdc2084048bebe5bd9ea4fb97f7ece16df0

    in stead of:

    Code
    git bisect good 770ad5614e7e8074133e6f563495ce4822f63fe4
git bisect bad 19f8fcdc2084048bebe5bd9ea4fb97f7ece16df0
git bisect start
    • New

    Hi,

    I got an error on the first bisect. There is no possibility to answer Y to this question.

    Code
    Reversed (or previously applied) patch detected!  Assume -R? [n] 
Apply anyway? [n]

    Do I have to add the -R option in the build command: PROJECT=Generic ARCH=x86_64 make -R image

    More info:

    • New

    When building a package the build-system downloads and unpacks package sources, applies patches, then compiles the package. In this case it fails during patching because the patch contains changes that already exist in the source so the patch cannot be applied. In this specific case delete the patch with "rm packages/network/bluez/patches/bluez-12-fix-obexd-after-5_73.patch" then re-run the build command and compile should succeed. Beyond some point in the timeline of changes/commits between v5.72 and v5.73 the patch might be required again (the compile might fail) in which case you can restore the patch (undo the delete) by checking it out from git with "git checkout packages/network/bluez/patches/bluez-12-fix-obexd-after-5_73.patch" and re-running the image build command again.

    • New

    The build fails on another patch. However log output is somewhat different than with the OBEX patch. Should I delete this patch also and reintroduce it when required?

    • New

    Yes, delete the patch for this test. Just be aware that later tests may require you to reinstate (checkout) the patch again.

    NB: "PROJECT=Generic ARCH=x86_64 scripts/unpack bluez" will only unpack/patch the package and "scripts/build bluez" will build the package without requiring the full "walk the tree" process of the buildsystem. It might help speed up the initial "get the patches right" process. If all is good the "make image" command will then package everything into an image.

    • New

    Ok, first bisect finished:

    More details of what I did:

    • New

    gobex: const annotate RO arrays, use G_N_ELEMENTS: I'm having some doubts that a change to an obex lib is causing your keyboard error.

    There may be false negatives (e.g. detection of the BT keyboard is delayed) interrupting the bisect process.

    • New
    Quote from mglae

    gobex: const annotate RO arrays, use G_N_ELEMENTS: I'm having some doubts that a change to an obex lib is causing your keyboard error.

    There may be false negatives (e.g. detection of the BT keyboard is delayed) interrupting the bisect process.

    I was a bit surprised too that a file transfer lib has something to do with the keyboard error I'm experiencing. One question though, you talking about false negatives interrupting the bisect process e.g. detection of the BT keyboard is delayed. Must the keyboard be connected to the build system during the bisect process? Maybe I do not fully understand the bisect process, I have little experience in coding.

    • New

    You do need reliable test procedures for a successful bisect process. Here the test is to connect the keyboard to the test system, nothing is required on the build system.

    If the keyboard is detected you do have a "good" case, no questions. But without detection: is this caused by the code error ("bad") or only a temporary fault?

    From your experience with working code (even in LE11, LE10 ...): how reliable is the keyboard detected?

    Maybe you need more boot tries if you see "bad". This is only a suggestion. Your experience is required to optimize the bisect test procedure.

    • New
    Quote from mglae

    You do need reliable test procedures for a successful bisect process. Here the test is to connect the keyboard to the test system, nothing is required on the build system.

    If the keyboard is detected you do have a "good" case, no questions. But without detection: is this caused by the code error ("bad") or only a temporary fault?

    From your experience with working code (even in LE11, LE10 ...): how reliable is the keyboard detected?

    Maybe you need more boot tries if you see "bad". This is only a suggestion. Your experience is required to optimize the bisect test procedure.

    I'm using this keyboard as from LE09. As far as I remember I never had any problems using this keyboard. When booting a bisect image test version I do the following:

    1. I go to LibreElec --> Bluetooth.
    2. I switch on the keyboard and push the connect button.
    3. A keyboard entry appears in the bluetooth list and after a few seconds its name (LogiTech Dinovo Edge) appears.
    4. I select pair on LE.
    5. I can confirm the password given by LE on the keyboard so at this stage keystrokes are send, detected an treated.
    6. After pairing there is no response anymore.

    So the error must appear somewhere after the pairing process or in the last stage of the pairing process itself.

    As for a reliable test procedure I can think of:

    1. I open two ssh terminal windows to the bisected LE to be tested.
    2. I Switch on the keyboard and push connect button and do bluetoothctl info 00:1F:20:04:44:38 to see if it is properly detected.
    3. In the second ssh terminal i start udevadm monitor I pair the keyboard to see what happens.
    4. In the first ssh terminal I can use evtest and journalctl -r -u bluetooth to see if there are anomalies.
    5. Maybe cross reference the above results between a "good" and a "bad" version?

    And what about adding the --enable-hid2hci option you mentioned earlier, to packages/network/bluez/package.mk when creating the first bisect image? If there are only "good" results it may be just this missing option?

    What do you think?

    • New

    Usually re-pairing is not required. Latest connection is stored in the keyboard and in LE below /storage/.config/bluetooth/. Do you boot "live" or "run"?

    Quote from ehoitinga

    And what about adding the --enable-hid2hci option

    Was not included inLE10 and LE11, so likely not required. But just do the simple test and the question is finally answered.