the startup screen asking to choose an init to use doesn’t support some faster keyboards (corsair 70m2 in this case)

[ghost]

no idea how to properly describe this, but modern mechanical keyboards don’t seem to work.

[paradigm]

This is a known issue:

https://bedrocklinux.org/0.7/known-issues.html#init-menu-no-keyboard

There are some work-arounds there which should get you going despite the issue.

I have been unable to reproduce the issue myself locally. I've tried to debug it by proxy with others in the past without success. If you have the time and patience, I'm happy to work with you on debugging it by proxy - maybe we'll get lucky where it didn't work out with others. Let me know and I'll type up some instructions to collect debug information.

[ghost]

I would be willing to do some debugging as this and [somehow bedrock breaks kwin on nv proprietary] are the only issues I have. I have a testing laptop I can use.

I’ve seen this issue on my hp prodesk (I use as a server) in the bios so this is not exclusive to bedrock.

how can I easily get in contact for fast communication? irc?

also should I use 0.7.8b1 or stable? it persists on both.

[paradigm]

I would be willing to do some debugging as this

As root, make a script at /bedrock/debug.sh with the following contents:

#!/bedrock/libexec/busybox sh
run() {
    echo '$ '"${*}"
    eval "${@}" 2>&1 | sed 's/^/    /'
    echo ""
}
run "lsmod"
run "ls -laR /dev/"
run "ps"
run "dmesg"

That script should gather everything I can think of that could be relevant.

Then open /bedrock/strata/bedrock/sbin/init and go to get_init_choice() {, somewhere around like 232. Right after that add:

    sh /bedrock/debug.sh > /bedrock/init-log

so with context it looks like:

get_init_choice() {
    sh /bedrock/debug.sh > /bedrock/init-log
    echo "Select init number to use for this session" >&2

Then reboot. Wait out the timeout at the init selection menu. Once you're logged into the system, run:

sh /bedrock/debug.sh > /bedrock/runtime-log

and finally gist/hastebin/whatever the contents of both /bedrock/init-log and /bedrock/runtime-log. Hopefully by comparing and contrasting those two files I'll be able to see what's changed that makes the keyboard work where it didn't before.

I’ve seen this issue on my hp prodesk (I use as a server) in the bios so this is not exclusive to bedrock.

That's interesting. So it's probably not using standard USB HID. However, your keyboard works once you're in the system, right? So something about the Linux stack knows how to use it at some point.

how can I easily get in contact for fast communication? irc?

Affirmative. Assuming I'm available, that's the best way to reach me in real time.

also should I use 0.7.8b1 or stable? it persists on both.

Doesn't matter. None of the changes between the two are relevant here.

[ghost]

hey paradigm if you are still there, somehow editing that file fixed typing in the init selection menu. no idea how one of the commands in the sh file or just adding the line fixed it https://hastebin.com/etobuhulod.coffeescript init-log https://hastebin.com/umubacanes.coffeescript runtime-log I think it uses the standard usb hid but it tries to tell the OS to update the input faster/will attempt to use a driver if it is sent the correct proprietary code (ask the guys at ckb-next they might know more about this).

[paradigm]

hey paradigm if you are still there, somehow editing that file fixed typing in the init selection menu. no idea how

Oooooh. Perhaps the issue is that it takes the kernel longer to initialize your keyboard than it does to get to Bedrock's init selection menu. I hadn't considered that before. If the debug code takes long enough that might fix it for you as a side effect.

Looking at the debug information you provided, I see:

[ 0.590742] devtmpfs: initialized

This indicates that about half a second in Bedrock asks the kernel to start preparing access to the various hardware devices, including the keyboard.

[ 2.077254] hid-generic 0003:046D:C53F.0001: input,hidraw0: USB HID v1.11 Keyboard [Logitech USB Receiver] on usb-0000:00:14.0-5/input0

This indicates the keyboard wasn't ready until about two seconds in.

On my system - which does not reproduce the issue - the keyboard is ready much faster for whatever reason.

I think we might finally figured out what is going on with this issue!

---

The question now is how to fix it properly.

• I don't know of a good way to just wait for devtmpfs to settle (i.e., an equivalent to udevadm --settle).
• I could poll on waiting for a keyboard to be available, such as waiting for a /dev/input/by-path/*-kbd file. However, I have concerns around false negatives in case somehow a keyboard-like device becomes available through some other means I'm not familiar with. Or if the user doesn't want to use a keyboard at all.
• I could look into making the code that reads your input figure out input is not available and try again. I'm not really sure how to do this, though.

I'll think about it for a bit. At some point I'll probably experiment with a strategy and release it in the beta channel for you to resolves the issue for you and for others to confirm doesn't break anything.

For the time being, I guess keep the debug around if it helps. It might get overridden in a brl update - if so, just let it timeout/default through then re-add the debug.

[paradigm]

I pushed a potential fix to master. It should be included in the next beta release for testing.

[ghost]

closed unless 0.7.8b2 has this issue or it reappears later

[paradigm]

@A-Human-Person I pushed 0.7.8beta2 with the fix. Please test it and let me know if it resolves the issue for you.

[ghost]

will test later, thanks.

[ghost]

hey paradigm, just want to make sure that 0.7.8b2 has a configuration option to disable the keyboard check since some people might want it disabled so it goes right to the OS (for users with extremely slow loading keyboards (5s or more)) otherwise this issue seems completely solved

[paradigm]

Yes it does. It uses the timeout field under [init] in /bedrock/etc/bedrock.conf. If you always want it to use the default configured init and bypass the init selection menu, you can set it to 0. This will skip the keyboard initialization delay.

[ghost]

nice, this seems ready for stable.