1. Its class is HID, subclass and protocol are 0. It's just a regular
HID device only with its own custom report descriptor.
2. `grub_term_input` which is pretty much the only user input
mechanism in GRUB (as far as I could understand the code, I might be
wrong) expects keycodes, but the reports th
From: Prarit Bhargava
The GRUB_DISABLE_SUBMENU option is different than the others in the sense
that it has to be set to "y" instead of "true" to be enabled.
That causes a lot of confusion to users, some may wrongly set it to "true"
expecting that will work the same than with most options, and s
From: Peter Jones
The grub-mkconfig and 10_linux scripts by default attempt to use a UUID to
set the root kernel command line parameter and the $root GRUB environment
variable.
The former can be disabled by setting the GRUB_DISABLE_LINUX_UUID variable
to "true", but there is currently no way to
Extend partition UUID probing support in GRUB core to display pseudo partition
UUIDs for MBR (MSDOS) partitions.
Signed-off-by: Nicholas Vinson
---
grub-core/commands/probe.c | 43 +-
1 file changed, 29 insertions(+), 14 deletions(-)
diff --git a/grub-core/co
Patch looks good in concept but I have few questions:
1. How is it different from normal HID
2. Why do you do custom mapping I'm the driver, why not just pass the
events pretty much as is
3. Why is it predicated on a particular device model rather than on device
class?
On Sun, 29 Sep 2019, 15:59 A
Also we need to add safeguards to never fill more than half of variable
storage, same as Linux. Just to avoid bricking bad firmwares
On Mon, 30 Sep 2019, 13:16 Daniel Kiper, wrote:
> On Sun, Sep 15, 2019 at 05:14:02PM +0200, Sam van Kampen via Grub-devel
> wrote:
> > Hey all,
> >
> > To solve a
On Thu, Aug 29, 2019 at 01:37:14PM -0700, BJ Black wrote:
> Hi all!
>
> I recently experienced a problem on a fleet of CentOS 6 boxes with GRUB
> 0.97 that had a dodgy CMOS battery and the RTC was broken. In this
> circumstance, the timeout on the GRUB menu never moved because GRUB
> didn't think
On Sun, Sep 15, 2019 at 05:14:02PM +0200, Sam van Kampen via Grub-devel wrote:
> Hey all,
>
> To solve a problem I faced on my own system I've been working on a
> patch that adds support for viewing and editing EFI Boot* variables
> (BootOrder, BootNext, Boot) from GRUB, and was wondering if th
