It seems this closed the following PR:

In D47571#1103785, @stephane.rochoy_stormshield.eu wrote:

NCT6126D

0xd284

In D49982#1140083, @ziaee wrote:

Can we have an updated version string in the dmesg? On current with nvidia-drm-66-kmod, I get:

Initialized nvidia-drm 0.0.0 20160202 for nvidia0 on minor 1

In D49982#1140088, @junchoon_dec.sakura.ne.jp wrote:

In D49982#1140083, @ziaee wrote:

Can we have an updated version string in the dmesg? On current with nvidia-drm-66-kmod, I get:

Initialized nvidia-drm 0.0.0 20160202 for nvidia0 on minor 1

Cannot find related codes in nvidia side of src in quick glance, but found in drm-*-kmod part.
(I'm working on stable/14, so cannot test graphics/*drm-66-kmod. But string in dmesg looks same.

I tried gop blt off on my old laptop and it worked there. Surprisingly, gop blt off case is significantly *slower* than gop blt on case.

In D49073#1119520, @tsoome wrote:

In D49073#1119458, @jkim wrote:

In this case, I can see gop blt off is significantly faster.

faster than 'blt on' with the same resolution? It definitely is faster than 4K resolution.

In D49073#1119340, @tsoome wrote:

In D49073#1119317, @jkim wrote:

Unfortunately, I do not see anything on screen if I do gop blt off. *Blindly* typing gop blt on makes it start printing characters again. Maybe pixel color is wrong, e.g., background color == foreground color?

use 'gop get' and see if it reports framebuffer address., or better yet, can you paste the output?

Unfortunately, I do not see anything on screen if I do gop blt off. *Blindly* typing gop blt on makes it start printing characters again. Maybe pixel color is wrong, e.g., background color == foreground color?

I updated the patch to revert rGe1ebda4458bb and re-apply my patch.

Gleb added a stopgap in rGe1ebda4458bb but I don't like it because we will have vfs.ffs node in MINIMAL kernel.

I found some time and tried it on Intel Core 8th gen laptop.

LGTM

LGTM

In D47472#1082752, @kevans wrote:

In D47472#1082711, @jkim wrote:

Although Hangul Jamo charaters occupy space, it seems many implementations use zero-width nowadays, including GNU libc.

https://sourceware.org/bugzilla/show_bug.cgi?id=19852
https://github.com/ridiculousfish/widecharwidth/issues/16

I agree that we should follow other implementations.

However, all fillers must occupy proper spaces, i.e., <HANGUL_CHOSEONG_FILLER> => 2, <HANGUL_JUNGSEONG_FILLER> => 0, and <HALFWIDTH_HANGUL_FILLER> => 1.

Ah, ok, thanks for confirming that- so if I just drop the ignorable check, the fillers return to their previous value with exception to <HANGUL_JUNGSEONG_FILLER> since it falls in the Hangul Kamo range that we're forcing to zero-width. That looks right based on what you've written, since omitted values default to 1.

Although Hangul Jamo charaters occupy space, it seems many implementations use zero-width nowadays, including GNU libc.

LGTM

LGTM

LGTM