Posts by ehoitinga

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

    I build a fresh image from master. After that I added the option --enable-hid2hci to the file packages/network/bluez/package.mk and rebuild the image. As you predicted nothing changed. So this question is finally answered. --enable-hid2hci is not needed.

    Will continue with a fresh bisect run. I'll keep you informed.

    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"?

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

    I use the "run" option. Every image build is written freshly to the USB stick. I don't use SFTP/update

    Indeed the option --enable-hid2hci is likely not required. I can't hurt to try. As you say, the question will be finally answered.

    Will start a fresh bisect process with the mentioned test procedure. I'll keep posting the results.

    Thanks a lot so far.

    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?

    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.

    Ok, first bisect finished:

    More details of what I did:

    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?

    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:

    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

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


    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".

    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 :)

    Change download source:

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

    Just checkout and build master as the start point. For what we're doing there's no need to commit/save changes.

    I'm getting an error when building the image:

    It seems that commons-text-1.11.0-bin.tar.gz is not available.

    Ubuntu minimial with openssh is all that's required; then you can SSH into the VM to install prerequisites and clone sources. There's no need for the GUI environment too, but I guess for some users Terminal access will be easier than SSH.

    I'm not sure about the git checkout command. Should it be git checkout 11.95.2 or git checkout 12.0 ? I suppose it is git checkout 11.95.2 to checkout on the latest release in the 12.0 branch?

    Have a read: https://wiki.libreelec.tv/development/build-basics

    First step is to build the current LE master branch (LE12). Once that results in a working image that you can boot, we can describe how to bisect the changes.

    Installing Ubuntu 22.04 on a virtual machine as build environment. Is suppose it is just a standard installation. Is there any need to install this:

    Will a minimal installation be ok? Think there is no need for all the fancy stuff.

    ehoitinga this updates bluez to potentially address a DualShock BT device issue. You may want to test this for your scenario

    LE12 image with bluez 5.75+. https://heitbaum.libreelec.tv/LibreELEC-Gene…-f46fff4.img.gz includes https://github.com/LibreELEC/LibreELEC.tv/pull/8820

    Thanks for the image! I just tried it but unfortunately is does not address the issue I have with the Dinovo Edge keyboard.

    Have you ever self-built an LE image? i.e. if you have/can we can coach on how to bisect the changes. If we have to make images for you to test and report back which worked/didn't work it's the same process .. but it'll be a lot slower.

    No, I never built an LE image but I can try. Think it starts with a proper build environment? Can this be done in a mint installation on a Virtual Machine? Or maybe a Docker container?

    Ok, after fresh module build when updating my Mint laptop to kernel 6.5.0-27-generic the keyboard is working again.

    So now I'm sure the keyboard itself is working.

    Details of bluez version installed on my laptop:

    So what can be the issue in LE? Bluez?

    Perhaps the changes regarding Bluetooth in kernel 6.6.21?

    Are you able to boot your Mint with an older kernel like 6.5.0-21?

    My kernel is on 6.5.0-26-generic (Mint 21.1). I don't think it is a kernel problem, at least not in the kernel itself. I suspect Bluez and more precise the Bluez kernel module.

    Bluez v.5.64 on my laptop and v.5.73 on LE 11.95.1.

    The newest nightly LE build has Bluez version 5.72, and the keyboad is working here. So I should say something changed in Bluez 5.72 --> 5.73. But why is is not working on my mint laptop with Bluez v.5.64?


    Sorry for quoting myself, couldnt find any editing option ... Anyway, that's what i forgot to mention:

    I am using the provided Logitech USB dongle which makes the whole thing work out of the box without even having to enable bluetooth within LE. Maybe that's why it is still working for me ...

    I also thought of using this but I can't find it anywhere :(

    We are talking about this dongle isn't it?

    diNovo Edge™ - Logitech Support


    Unfortunately the changes do include kernel (6.6.19 to 6.6.21) and bluez (5.72 to 5.73) updates.

    So it should be caused by some change in 5.72 to 5.73 (https://github.com/bluez/bluez/compare/5.72...5.73)?