kernel/git/next/linux-next.git/drivers/tty/vt/ucs.c, branch stable

vt: merge ucs_is_zero_width()/ucs_is_double_width() into ucs_get_width()

2026-05-22T09:47:33+00:00

The hot path in vc_process_ucs() asks two independent questions about the same code point -- "is it double-width?" and "is it zero-width?" -- and was answering each with its own bsearch over its own table. For anything past the leading bounds check that meant two scans of the BMP width tables back to back for what is logically a single lookup. Replace both with one ucs_get_width(cp) returning 0, 1, or 2 in a single bsearch, while keeping the total table footprint at the same 2384 B as before. To do so, merge the zero-width and double-width ranges per region into one sorted-by-`first` table. BMP entries stay 4 bytes; per-entry width is hosted in spare bits of the non-BMP table's `last` field. Non-BMP code points use only 20 of 32 bits, so each u32 has 12 unused high bits. Store first/last shifted left by 12 and use the low 12 bits of `last` for metadata: bit 11 is this entry's own width flag, bits 0..7 host an 8-bit chunk of the BMP double-width bitmap. Because the metadata bits sit strictly below the lowest cp-scale bit, the bsearch comparator remains a plain u32 compare on shifted keys with no masking. In vc_process_ucs() the overwhelmingly common single-width path now collapses to a single predicted branch: if (likely(w == 1)) return 1; Note: scripts/checkpatch.pl complains about "Macros with complex values should be enclosed in parentheses" for the BMP_*WIDTH and RANGE_*WIDTH macros. They are deliberately defined to expand to a comma-separated (first, last) pair so they can populate the two adjacent fields of a struct initializer; wrapping them in parentheses would turn that into a comma-expression and defeat the whole construction. Please ignore. Signed-off-by: Nicolas Pitre Link: https://patch.msgid.link/20260515034857.2514225-1-nico@fluxnic.net Signed-off-by: Greg Kroah-Hartman

vt: fix kernel-doc warnings in ucs_get_fallback()

2025-06-19T11:27:36+00:00

Use the correct function parameter name in ucs_get_fallback() to prevent kernel-doc warnings: Warning: drivers/tty/vt/ucs.c:218 function parameter 'cp' not described in 'ucs_get_fallback' Warning: drivers/tty/vt/ucs.c:218 Excess function parameter 'base' description in 'ucs_get_fallback' Fixes: fe26933cf1e1 ("vt: add ucs_get_fallback()") Signed-off-by: Randy Dunlap Cc: Nicolas Pitre Cc: Greg Kroah-Hartman Cc: Jiri Slaby Cc: linux-serial@vger.kernel.org Reviewed-by: Nicolas Pitre . Link: https://lore.kernel.org/r/20250611020229.2650595-1-rdunlap@infradead.org Signed-off-by: Greg Kroah-Hartman

vt: process the full-width ASCII fallback range programmatically

2025-05-21T11:39:45+00:00

This shaves about 170 bytes from ucs.o. Signed-off-by: Nicolas Pitre Link: https://lore.kernel.org/r/20250507141535.40655-9-nico@fluxnic.net Signed-off-by: Greg Kroah-Hartman

vt: add ucs_get_fallback()

2025-05-21T11:39:45+00:00

This is the code querying the newly introduced tables. Signed-off-by: Nicolas Pitre Link: https://lore.kernel.org/r/20250507141535.40655-7-nico@fluxnic.net Signed-off-by: Greg Kroah-Hartman

vt: ucs.c: fix misappropriate in_range() usage

2025-05-21T11:39:45+00:00

The in_range() helper accepts a start and a length, not a start and an end. Signed-off-by: Nicolas Pitre Reviewed-by: Jiri Slaby Link: https://lore.kernel.org/r/20250507141535.40655-2-nico@fluxnic.net Signed-off-by: Greg Kroah-Hartman

vt: refresh ucs_width_table.h and adjust code in ucs.c accordingly

2025-04-26T09:22:04+00:00

Width tables are now split into BMP (16-bit) and non-BMP (above 16-bit). This reduces the corresponding text size by 20-25%. Note: scripts/checkpatch.pl complains about "... exceeds 100 columns". Please ignore. Signed-off-by: Nicolas Pitre Reviewed-by: Jiri Slaby Link: https://lore.kernel.org/r/20250417184849.475581-14-nico@fluxnic.net Signed-off-by: Greg Kroah-Hartman

vt: support Unicode recomposition

2025-04-26T09:22:04+00:00

Try replacing any decomposed Unicode sequence by the corresponding recomposed code point. Code point to glyph correspondance works best after recomposition, and this apply mostly to single-width code points therefore we can't preserve them in their decomposed form anyway. Signed-off-by: Nicolas Pitre Reviewed-by: Jiri Slaby Link: https://lore.kernel.org/r/20250417184849.475581-10-nico@fluxnic.net Signed-off-by: Greg Kroah-Hartman

vt: use new tables in ucs.c

2025-04-26T09:22:03+00:00

This removes the table from ucs.c and substitutes the generated tables from ucs_width_table.h providing comprehensive ranges for double-width and zero-width Unicode code points. Also implements ucs_is_zero_width() to query the new zero-width table. Signed-off-by: Nicolas Pitre Reviewed-by: Jiri Slaby Link: https://lore.kernel.org/r/20250417184849.475581-7-nico@fluxnic.net Signed-off-by: Greg Kroah-Hartman

vt: move unicode processing to a separate file

2025-04-26T09:22:03+00:00

This will make it easier to maintain. Also make it depend on CONFIG_CONSOLE_TRANSLATIONS. Signed-off-by: Nicolas Pitre Reviewed-by: Jiri Slaby Link: https://lore.kernel.org/r/20250417184849.475581-3-nico@fluxnic.net Signed-off-by: Greg Kroah-Hartman