From: Janne Grunau
efi_console / UEFI applications (grub2, sd-boot, ...) pass UTF-8
character sequences to vidconsole which results in wrong glyphs for code
points outside of ASCII. The truetype console expects Unicode code
points and bitmap font based consoles expect code page 437 code points.
From: Andre Przywara
UEFI relies entirely on unicode output, which actual fonts displayed on
the screen might not be ready for.
Add a test displaying some international characters, to reveal missing
glyphs, especially in our builtin fonts.
This would be needed to be manually checked on the
From: Janne Grunau
Code page 437 uses code points 1-31 for glyphs instead of control
characters. Map the appropriate Unicode code points to this code points.
Fixes rendering of grub2's menu as EFI application using the
EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL on a console with bitmap fonts.
From: Janne Grunau
Draw symbols from code page 437 code points 0x01 - 01f used by UEFI
applications to draw user interfaces using
EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL.
Add a simple test to displaying the Konami code using symbols used by
grub2. The output has to be checked manually on the screen for
Andre submitted 2 years ago DM_VIDEO improvements for UEFI applications
using UEFI's EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL but did not follow with
suggested changes. This series takes care of the UTF-8 support which
required to draw symbol and box drawing characters used by UEFI
applications like grub2
From: Janne Grunau
Suggested-by: Heinrich Schuchardt
Signed-off-by: Janne Grunau
---
include/charset.h | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/include/charset.h b/include/charset.h
index 44034c71d3..f1050c903d 100644
--- a/include/charset.h
+++
From: Andre Przywara
UEFI applications rely on Unicode output capability, and might use that
for drawing pseudo-graphical interfaces using Unicode defined box
drawing characters.
Add a simple test to display the most basic box characters, which would
need to be checked manually on the screen
From: Janne Grunau
Apple USB keyboards carry the HID keyboard boot protocol on the second
interface. Using the second interface in the USB keyboard driver does
not work since the xhci has not allocated a transfer ring.
---
drivers/usb/host/xhci.c | 31 +++
From: Janne Grunau
Those keyboards do not return the current device state. Polling will
timeout unless there are key presses. This is not a problem during
operation but the inital device state query during probing will fail.
Skip this step in usb_kbd_probe_dev() to make these devices useable.
From: Janne Grunau
Discovered while trying to use the second interface in the USB keyboard
driver necessary on Apple USB keyboards.
Signed-off-by: Janne Grunau
---
drivers/usb/host/xhci-ring.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/usb/host/xhci-ring.c
From: Hector Martin
We currently only support one USB keyboard device, but some devices
emulate keyboards for other purposes. Most commonly, people run into
this with Yubikeys, so let's ignore those.
Even if we end up supporting multiple keyboards in the future, it's
safer to ignore known
From: Janne Grunau
Apple USB keyboards (Magic Keyboard from 2021 (product id 0x029c)) carry
the HID keyboard boot protocol on the second interface descriptor.
Probe via vendor and product IDs since the class/subclass/protocol match
uses the first interface descriptor.
Probe the two first
From: Janne Grunau
In the next step endpoints for multiple interfaces are set up. Move most
of the per endpoint initialization to separate function to avoid another
identation level.
Signed-off-by: Janne Grunau
---
drivers/usb/host/xhci.c | 119 +---
Apple USB Keyboards from 2021 need quirks to be useable. The boot HID
keyboard protocol is unfortunately not described in the first interface
descriptor but the second. This needs several changes. The USB keyboard
driver has to look at all (2) interface descriptors during probing.
Since I didn't
Andre submitted 2 years ago DM_VIDEO improvements for UEFI applications
using UEFI's EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL but did not follow with
suggested changes. This series takes care of the UTF-8 support which
required to draw symbol and box drawing characters used by UEFI
applications like grub2
From: Janne Grunau
efi_console / UEFI applications (grub2, sd-boot, ...) pass UTF-8
character sequences to vidconsole which results in wrong glyphs for code
points outside of ASCII. The truetype console expects Unicode code
points and bitmap font based consoles expect code page 437 code points.
From: Andre Przywara
UEFI applications rely on Unicode output capability, and might use that
for drawing pseudo-graphical interfaces using Unicode defined box
drawing characters.
Add a simple test to display the most basic box characters, which would
need to be checked manually on the screen
From: Janne Grunau
Add mappings for code points 1 - 31 as those code points in code page 437
are graphics.
Thios fixes rendering issues of various EFI boot loaders (grub2,
sd-boot, ...) using EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL.
Signed-off-by: Janne Grunau
---
include/charset.h
From: Janne Grunau
Draw symbols from code page 437 code points 0x01 - 01f used by UEFI
applications to draw user interfaces using
EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL.
Add a simple test to displaying the Konami code using symbols used by
grub2. The output has to be checked manually on the screen for
From: Janne Grunau
The comment appears to be copied from utf8_to_cp437_stream() but was not
updated.
Signed-off-by: Janne Grunau
---
include/charset.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/charset.h b/include/charset.h
index 44034c71d3..714382e1c1 100644
From: Janne Grunau
vidconsole_ops.get_font is documented to return -ENOENT after the last
video_fontdata entry.
Signed-off-by: Janne Grunau
---
drivers/video/console_core.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/video/console_core.c
From: Janne Grunau
Without explicit support for VIDEO_X2R10G10B10 VIDEO_X8R8G8B8 white
will be rendered as cyan-ish. The conversion leaves to lowest 2 bits
unset for more compact code.
Signed-off-by: Janne Grunau
---
drivers/video/console_truetype.c | 10 --
1 file changed, 8
From: Andre Przywara
UEFI relies entirely on unicode output, which actual fonts displayed on
the screen might not be ready for.
Add a test displaying some international characters, to reveal missing
glyphs, especially in our builtin fonts.
This would be needed to be manually checked on the
From: Janne Grunau
The memory maps for Apple's M2 Pro/Max/Ultra left MMIO space out which
was not used by any driver at the time. The display out exposed as
simple-framebuffer use a power-domain controlled by a device in an
unmapped region.
Add a map covering this region as well as another MMIO
From: Janne Grunau
The memory maps for Apple's M2 Pro/Max/Ultra left MMIO space out which
was not used by any driver at the time. The display out exposed as
simple-framebuffer use a power-domain controlled by a device in an
unmapped region.
Add a map covering this region as well as another MMIO
From: Janne Grunau
Use standard boot instead of the distro boot scripts. Use
BOOTSTD_FULL instead of BOOTSTD_DEFAULTS for easier interactive use.
Signed-off-by: Janne Grunau
---
arch/arm/Kconfig| 2 +-
include/configs/apple.h | 20 ++--
2 files changed, 3
From: Janne Grunau
The display size querying in efi_console relies on this order. The
display should be the primary output device and should be used to
display more than 80x25 chars.
Reviewed-by: Mark Kettenis
Reviewed-by: Neal Gompa
Signed-off-by: Janne Grunau
---
include/configs/apple.h |
This series contains a few misc config changes for Apple silicon
systems:
- switch from the deprecated distro boot scripts to standard boot
- allows EFI console resizing based on the video console size
- enables 16x32 bitmap fonts as Apple devices come with high DPI
displays
- enables 64-bit LBA
From: Hector Martin
This makes USB HDDs >2TiB work. The only reason this hasn't bitten us
for the internal NVMe yet is the 4K sector size, because the largest SSD
Apple sells is 8TB and we can handle up to 16TiB with that sector size.
Close call.
Signed-off-by: Hector Martin
Reviewed-by: Mark
From: Janne Grunau
The bootflow list is only seen briefly and is probably more confusing
than helpful.
Signed-off-by: Janne Grunau
---
configs/apple_m1_defconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/configs/apple_m1_defconfig b/configs/apple_m1_defconfig
index
From: Janne Grunau
Apple devices have high DPI displays so the larger fonts are preferable
for improved readability. This does not yet change the used font based
on the display's pixel density so the standard 8x16 font is still used
by default.
Reviewed-by: Mark Kettenis
Reviewed-by: Neal
From: Janne Grunau
The display size querying in efi_console relies on this order. The
display should be the primary output device and should be used to
display more than 80x25 chars.
Signed-off-by: Janne Grunau
---
include/configs/apple.h | 4 ++--
1 file changed, 2 insertions(+), 2
From: Janne Grunau
Apple devices have high DPI displays so the larger fonts are preferable
for improved readability. This does not yet change the used font based
on the display's pixel density so the standard 8x16 font is still used
by default.
Signed-off-by: Janne Grunau
---
From: Hector Martin
This makes USB HDDs >2TiB work. The only reason this hasn't bitten us
for the internal NVMe yet is the 4K sector size, because the largest SSD
Apple sells is 8TB and we can handle up to 16TiB with that sector size.
Close call.
Signed-off-by: Hector Martin
Signed-off-by:
From: Janne Grunau
Use standard boot instead of the distro boot scripts.
Signed-off-by: Janne Grunau
---
arch/arm/Kconfig| 2 +-
include/configs/apple.h | 20 ++--
2 files changed, 3 insertions(+), 19 deletions(-)
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
This series contains a few misc config changes for Apple silicon
systems:
- switch from the deprecated distro boot scripts to standard boot
- allows EFI console resizing based on the video console size
- enables 16x32 bitmap fonts as Apple devices come with high DPI
displays
- enables 64-bit LBA
From: Janne Grunau
Discovered while trying to use the second interface in the USB keyboard
driver necessary on Apple USB keyboards.
Reviewed-by: Marek Vasut
Reviewed-by: Neal Gompa
Signed-off-by: Janne Grunau
---
drivers/usb/host/xhci-ring.c | 5 +
1 file changed, 5 insertions(+)
diff
Apple USB Keyboards from 2021 need quirks to be useable. The boot HID
keyboard protocol is unfortunately not described in the first interface
descriptor but the second. This needs several changes. The USB keyboard
driver has to look at all (2) interface descriptors during probing.
Since I didn't
From: Janne Grunau
Add the environment variable "usb_ignorelist" to prevent USB devices
listed in it from being bound to drivers. This allows to ignore devices
which are undesirable or trigger bugs in u-boot's USB stack.
Devices emulating keyboards are one example of undesirable devices as
From: Janne Grunau
Those keyboards do not return the current device state. Polling will
timeout unless there are key presses. This is not a problem during
operation but the initial device state query during probing will fail.
Skip this step in usb_kbd_probe_dev() to make these devices useable.
From: Janne Grunau
The xhci driver currently only does the necessary initialization for
endpoints found in the first interface descriptor. Apple USB keyboards
(released 2021) use the second interface descriptor for the HID keyboard
boot protocol. To allow USB drivers to use endpoints from other
From: Janne Grunau
Apple USB keyboards (Magic Keyboard from 2021 (product id 0x029c)) carry
the HID keyboard boot protocol on the second interface descriptor.
Probe via vendor and product IDs since the class/subclass/protocol match
uses the first interface descriptor.
Probe the two first
From: Janne Grunau
In the next step endpoints for multiple interfaces are set up. Move most
of the per endpoint initialization to separate function to avoid another
identation level.
Reviewed-by: Marek Vasut
Reviewed-by: Neal Gompa
Signed-off-by: Janne Grunau
---
drivers/usb/host/xhci.c |
From: Janne Grunau
Code page 437 uses code points 1-31 for glyphs instead of control
characters. Map the appropriate Unicode code points to this code points.
Fixes rendering of grub2's menu as EFI application using the
EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL on a console with bitmap fonts.
Andre submitted 2 years ago DM_VIDEO improvements for UEFI applications
using UEFI's EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL but did not follow with
suggested changes. This series takes care of the UTF-8 support which
required to draw symbol and box drawing characters used by UEFI
applications like grub2
From: Andre Przywara
UEFI relies entirely on unicode output, which actual fonts displayed on
the screen might not be ready for.
Add a test displaying some international characters, to reveal missing
glyphs, especially in our builtin fonts.
This would be needed to be manually checked on the
From: Andre Przywara
UEFI applications rely on Unicode output capability, and might use that
for drawing pseudo-graphical interfaces using Unicode defined box
drawing characters.
Add a simple test to display the most basic box characters, which would
need to be checked manually on the screen
From: Janne Grunau
efi_console / UEFI applications (grub2, sd-boot, ...) pass UTF-8
character sequences to vidconsole which results in wrong glyphs for code
points outside of ASCII. The truetype console expects Unicode code
points and bitmap font based consoles expect code page 437 code points.
From: Janne Grunau
Draw symbols from Unicode's "Geometric shapes" page which translate to
code page 437 code points 1-31. These are used by UEFI applications to
draw user interfaces using EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL.
The output has to be checked manually on the screen for correctness.
From: Janne Grunau
Suggested-by: Heinrich Schuchardt
Reviewed-by: Heinrich Schuchardt
Signed-off-by: Janne Grunau
---
include/charset.h | 14 --
1 file changed, 12 insertions(+), 2 deletions(-)
diff --git a/include/charset.h b/include/charset.h
index 44034c71d3..f1050c903d
From: Janne Grunau
Test that Unicode code points which map to CP437 code points 1-31 are
converted to '_'. This ensures no FAT file names do not contain chars
which are control characters in other code pages (CP 1250 for example).
Signed-off-by: Janne Grunau
---
From: Janne Grunau
Add the environment variable "usb_blocklist" to prevent USB devices
listed in it from being used. This allows to ignore devices which
trigger bugs in u-boot's USB stack or are undesirable for other reasons.
Devices emulating keyboards are one example. U-boot currently supports
From: Janne Grunau
Those keyboards do not return the current device state. Polling will
timeout unless there are key presses. This is not a problem during
operation but the inital device state query during probing will fail.
Skip this step in usb_kbd_probe_dev() to make these devices useable.
From: Janne Grunau
In the next step endpoints for multiple interfaces are set up. Move most
of the per endpoint initialization to separate function to avoid another
identation level.
Reviewed-by: Marek Vasut
Signed-off-by: Janne Grunau
---
drivers/usb/host/xhci.c | 119
From: Janne Grunau
Discovered while trying to use the second interface in the USB keyboard
driver necessary on Apple USB keyboards.
Signed-off-by: Janne Grunau
---
drivers/usb/host/xhci-ring.c | 5 +
1 file changed, 5 insertions(+)
diff --git a/drivers/usb/host/xhci-ring.c
From: Janne Grunau
The xhci driver currently only does the necessary initialization for
endpoints found in the first interface descriptor. Apple USB keyboards
(released 2021) use the second interface descriptor for the HID keyboard
boot protocol. To allow USB drivers to use endpoints from other
From: Janne Grunau
Apple USB keyboards (Magic Keyboard from 2021 (product id 0x029c)) carry
the HID keyboard boot protocol on the second interface descriptor.
Probe via vendor and product IDs since the class/subclass/protocol match
uses the first interface descriptor.
Probe the two first
Apple USB Keyboards from 2021 need quirks to be useable. The boot HID
keyboard protocol is unfortunately not described in the first interface
descriptor but the second. This needs several changes. The USB keyboard
driver has to look at all (2) interface descriptors during probing.
Since I didn't
From: Janne Grunau
In the next step endpoints for multiple interfaces are set up. Move most
of the per endpoint initialization to separate function to avoid another
identation level.
Reviewed-by: Marek Vasut
Reviewed-by: Neal Gompa
Signed-off-by: Janne Grunau
---
drivers/usb/host/xhci.c |
From: Janne Grunau
The xhci driver currently only does the necessary initialization for
endpoints found in the first interface descriptor. Apple USB keyboards
(released 2021) use the second interface descriptor for the HID keyboard
boot protocol. To allow USB drivers to use endpoints from other
From: Janne Grunau
Apple USB keyboards (Magic Keyboard from 2021 (product id 0x029c)) carry
the HID keyboard boot protocol on the second interface descriptor.
Probe via vendor and product IDs since the class/subclass/protocol match
uses the first interface descriptor.
Probe the two first
Apple USB Keyboards from 2021 need quirks to be useable. The boot HID
keyboard protocol is unfortunately not described in the first interface
descriptor but the second. This needs several changes. The USB keyboard
driver has to look at all (2) interface descriptors during probing.
Since I didn't
From: Janne Grunau
Add the environment variable "usb_ignorelist" to prevent USB devices
listed in it from being bound to drivers. This allows to ignore devices
which are undesirable or trigger bugs in u-boot's USB stack.
Devices emulating keyboards are one example of undesirable devices as
From: Janne Grunau
Those keyboards do not return the current device state. Polling will
timeout unless there are key presses. This is not a problem during
operation but the initial device state query during probing will fail.
Skip this step in usb_kbd_probe_dev() to make these devices useable.
From: Janne Grunau
Discovered while trying to use the second interface in the USB keyboard
driver necessary on Apple USB keyboards.
Reviewed-by: Marek Vasut
Reviewed-by: Neal Gompa
Signed-off-by: Janne Grunau
---
drivers/usb/host/xhci-ring.c | 5 +
1 file changed, 5 insertions(+)
diff
65 matches
Mail list logo
