[gentoo-user] need help with amdgpu driver
I have a ryzen-7900X cpu but I cannot get the amdgpu driver up and running with my kernel 6.1.8 (uefi system) These are the errors dmesg shows: [0.668913] [drm] amdgpu: 512M of VRAM memory ready [0.668915] [drm] amdgpu: 31783M of GTT memory ready. [0.669819] amdgpu :0d:00.0: Direct firmware load for amdgpu/psp_13_0_5_ta.bin failed with error -2 [0.669823] amdgpu :0d:00.0: amdgpu: fail to initialize ta microcode [0.669828] [drm:amdgpu_device_init.cold] *ERROR* sw_init of IP block failed -2 [0.669831] amdgpu :0d:00.0: amdgpu: amdgpu_device_ip_init failed [0.669833] amdgpu :0d:00.0: amdgpu: Fatal error during GPU init [0.669834] amdgpu :0d:00.0: amdgpu: amdgpu: finishing device. [0.670042] amdgpu: probe of :0d:00.0 failed with error -2 [0.670046] amdgpu :0d:00.0: devm_attr_group_remove: removing group (ptrval) [0.670052] [drm] amdgpu: ttm finalized [0.907335] bus: 'pci': add driver pcie_mp2_amd [0.907411] bus: 'platform': add driver amd_pmc [1.007964] amd_hsmp: HSMP is not supported on Fam:19 model:61 [1.007967] amd_hsmp: Or Is HSMP disabled in BIOS ? [1.007968] bus: 'platform': add driver amd-pmf This is my .config # # Firmware loader # CONFIG_FW_LOADER=y CONFIG_FW_LOADER_PAGED_BUF=y CONFIG_FW_LOADER_SYSFS=y CONFIG_EXTRA_FIRMWARE="amd-ucode/microcode_amd_fam19h.bin amdgpu/psp_13_0_5_toc.bin" CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware" CONFIG_FW_LOADER_USER_HELPER=y # CONFIG_FW_LOADER_USER_HELPER_FALLBACK is not set CONFIG_FW_LOADER_COMPRESS=y CONFIG_FW_LOADER_COMPRESS_XZ=y CONFIG_FW_LOADER_COMPRESS_ZSTD=y # CONFIG_FW_UPLOAD is not set # end of Firmware loader I do not even get a console because of amdgpu gets not loaded. But I can log into the system via ssh because the system is a copy of my well running mbr system. My questions are: What firmware blobs of linux-firmware has to be installed to support the gpu of a ryzen-7900X? CONFIG_EXTRA_FIRMWARE=? I do not use initrd nor initramfs and all neccessary drivers are not installed as modules but compiled into the kernel. I it possible that a that moment the kernel cannot get blobs because the ext4 filesystem is not mounted already? So does one have to use initrd to get the blobs loaded? What is the meaning of "failed with error -2"? -- regards Klaus
Re: [gentoo-user] need help with amdgpu driver
Hello Klaus, have you made your kernel again after changing EXTRA_FIRMWARE ? Maybe you want read this: https://wiki.gentoo.org/wiki/User:Pietinger/Tutorials/ Manual_kernel_configuration#Driver_needs_Firmware Greetings, Peter Am Freitag, 27. Januar 2023, 11:08:58 CET schrieb Klaus Dittrich: > I it possible that a that moment the kernel cannot get blobs > because the ext4 filesystem is not mounted already? > So does one have to use initrd to get the blobs loaded? > > What is the meaning of "failed with error -2"?
Re: [gentoo-user] need help with amdgpu driver
On 27.01.23 12:17, Peter Böhm wrote: Hello Klaus, have you made your kernel again after changing EXTRA_FIRMWARE ? Maybe you want read this: https://wiki.gentoo.org/wiki/User:Pietinger/Tutorials/ Manual_kernel_configuration#Driver_needs_Firmware Greetings, Peter Am Freitag, 27. Januar 2023, 11:08:58 CET schrieb Klaus Dittrich: I it possible that a that moment the kernel cannot get blobs because the ext4 filesystem is not mounted already? So does one have to use initrd to get the blobs loaded? What is the meaning of "failed with error -2"? Peter, thanks for your answer. Sure, the machine is fast so a recompilation of the kernel is no problem. The error happens with and without "amdgpu/psp_13_0_5_ta.bin" in CONFIG_EXTRA_FIRMWARE as I discoverd meanwqhile. -- Regards Klaus
Re: [gentoo-user] Soft scrolling on framebuffer consoles - New version of the patch - with GPM handling.
On Thursday, 26 January 2023 20:28:36 GMT Alan Mackenzie wrote:
--->8
> Again, on any problems please let me know and I'll try to fix them. As
> ever, there are no guarantees, etc., etc., etc. My only promise is that
> there's no malicious code in the patch.
Good news! Well, partly... :)
I applied the new patch to 5.15.88 and it seems fine. I'll have to test it in
use and let you know.
Patching 6.1.8 failed, though, whereas the previous 5.15.80-scroll.
20221212.diff succeeded:
# patch -p1 < /usr/local/src/5.15.80-GPM.20230126.diff
patching file drivers/tty/vt/vt.c
Hunk #37 succeeded at 4748 (offset -1 lines).
Hunk #38 succeeded at 5049 (offset -1 lines).
Hunk #39 FAILED at 5353.
1 out of 39 hunks FAILED -- saving rejects to file drivers/tty/vt/vt.c.rej
patching file drivers/video/console/Kconfig
Hunk #1 succeeded at 99 (offset 1 line).
patching file drivers/video/fbdev/core/fbcon.c
Hunk #1 succeeded at 3171 (offset 19 lines).
patching file include/linux/console_struct.h
Hunk #2 FAILED at 170.
1 out of 2 hunks FAILED -- saving rejects to file include/linux/
console_struct.h.rej
patching file include/linux/vt_kern.h
Hunk #1 succeeded at 114 (offset -1 lines).
I've attached the reject files.
--
Regards,
Peter.
--- drivers/tty/vt/vt.c
+++ drivers/tty/vt/vt.c
@@ -5353,10 +5965,19 @@ EXPORT_SYMBOL_GPL(screen_glyph);
u32 screen_glyph_unicode(const struct vc_data *vc, int n)
{
- struct uni_screen *uniscr = get_vc_uniscr(vc);
+ int y = n / vc->vc_cols, x = n % vc->vc_cols;
+ uint32_t *ln = vc->vc_uniscr_curr + y * vc->vc_cols;
- if (uniscr)
- return uniscr->lines[n / vc->vc_cols][n % vc->vc_cols];
+ if (vc->vc_uniscr_curr) {
+ if (ln >= vc_uniscr_buf_end(vc))
+ ln -= vc->vc_uniscr_char_size;
+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK_GPM
+ ln -= vc->vc_softback_lines * vc->vc_cols;
+ if (ln < vc->vc_uniscr_buf)
+ ln += vc->vc_uniscr_char_size;
+#endif
+ return ln[x];
+ }
return inverse_translate(vc, screen_glyph(vc, n * 2), 1);
}
EXPORT_SYMBOL_GPL(screen_glyph_unicode);
--- include/linux/console_struct.h
+++ include/linux/console_struct.h
@@ -170,7 +181,11 @@ struct vc_data {
struct vc_data **vc_display_fg; /* [!] Ptr to var holding fg console for this display */
struct uni_pagedir *vc_uni_pagedir;
struct uni_pagedir **vc_uni_pagedir_loc; /* [!] Location of uni_pagedir variable for this console */
- struct uni_screen *vc_uni_screen; /* unicode screen content */
+#ifdef CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK_GPM
+ uint32_t *vc_uniscr_buf;/* Address of unicode screen content */
+ unsigned int vc_uniscr_char_size; /* Size of *vc-uniscr_buf in 32-bit chars */
+ uint32_t *vc_uniscr_curr; /* Pos of first char of (unscrolled) screen */
+#endif
/* additional information is in vt_kern.h */
};
Re: [gentoo-user] need help with amdgpu driver
Hello Klaus, Klaus Dittrich writes: > > The error happens with and without "amdgpu/psp_13_0_5_ta.bin" in > CONFIG_EXTRA_FIRMWARE as I discoverd meanwqhile. Your issue is most likely that you are missing firmware in the CONFIG_EXTRA_FIRMWARE setting. In my case there at 10 firmware blobs that I need in the kernel. Have you read the AMDGPU page on the Gentoo Wiki? Particularly the part about incorporating firmware blobs in the kernel? https://wiki.gentoo.org/wiki/Amdgpu#Unknown_firmware_blobs What I suggest is you change the AMDGPU driver back to a module rather than built it, and reboot once. Check DMESG (as explain in the link above) and it will show you every firmware that is loaded during boot. What that information you can update your CONFIG_EXTRA_FIRMWARE parameter with the proper values and put the AMDGPU driver back to built-in. -- Regards, Julien signature.asc Description: PGP signature
Re: Undeliverable: Re: [gentoo-user] Dolphin and adding a option, if it exists.
On Tuesday, 22 November 2022 21:58:45 GMT Dale wrote: > I'm top posting for those who want to ignore this message. > > This is the second message like this I've received. Is anyone else > getting these? Did someone close their email account and not > unsubscribe or something? Is this just me? I've just had one this morning, Dale. There seems to be a problem with missing SPF or DKIM in my outgoing messages. I'm in touch with my ISP about it. -- Regards, Peter.
Re: [gentoo-user] need help with amdgpu driver
Hi Klaus, CONFIG_EXTRA_FIRMWARE="amd-ucode/microcode_amd_fam19h.bin amdgpu/psp_13_0_5_toc.bin" CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware" [...] What firmware blobs of linux-firmware has to be installed to support the gpu of a ryzen-7900X? CONFIG_EXTRA_FIRMWARE=? I do not use initrd nor initramfs and all neccessary drivers are not installed as modules but compiled into the kernel. like you, I also use amdgpu hardcompiled into the kernel. It seems to be safe to include _all_ blobs in /lib/firmware/amdgpu. Then you can boot that kernel and check which blobs are actually necessary just by grepping though dmesg. Then you can boil down CONFIG_EXTRA_FIRMWARE to that set. This worked with several different AMD GPUs, RX 7900 included, but I never tried an integrated GPU/APU. Cheers Björn
Re: [gentoo-user] need help with amdgpu driver
Klaus Dittrich writes: > as I do not use a initrd or initramfs I am, as far as I know, forced > to compile the driver amdgpu into the kernel, not as modules to be > loaded. No, you can use modules even without an initrd. > I looked at https://wiki.gentoo.org/wiki/Amdgpu#Unknown_firmware_blobs > but I still do not know what name is relevant to the built-in-gpu > of a AMD-7900X processor.(!?) > > Does this gpu really needs all these blobs of the list there? > No, these blobs are given as examples. They vary per GPU models and in fact there are several hundred different blobs available: ls -l /lib/firmware/amdgpu | wc -l 479 So you have to figure out which ones you need. The easiest method is to let the kernel load them itself by having the driver built as a module, otherwise it may take several iterations of modifying the CONFIG_EXTRA_FIRMWARE value until you get it to work. -- Regards, Julien signature.asc Description: PGP signature
Re: [gentoo-user] need help with amdgpu driver
On 27.01.23 15:30, Julien Roy wrote: Klaus Dittrich writes: as I do not use a initrd or initramfs I am, as far as I know, forced to compile the driver amdgpu into the kernel, not as modules to be loaded. No, you can use modules even without an initrd. I looked at https://wiki.gentoo.org/wiki/Amdgpu#Unknown_firmware_blobs but I still do not know what name is relevant to the built-in-gpu of a AMD-7900X processor.(!?) Does this gpu really needs all these blobs of the list there? No, these blobs are given as examples. They vary per GPU models and in fact there are several hundred different blobs available: ls -l /lib/firmware/amdgpu | wc -l 479 So you have to figure out which ones you need. The easiest method is to let the kernel load them itself by having the driver built as a module, otherwise it may take several iterations of modifying the CONFIG_EXTRA_FIRMWARE value until you get it to work. Julien and Peter, now I (assume I) understand what you mean. The kernel needs the entries to CONFIG_EXTRA_FIRMWARE just for drivers to be compiled in and for modules just to reduce the seeking in /lib/firmware/amdgpu ? So when I set CONFIG_DRM_AMDGPU=m and then look at dmesg of the so compiled kernel it detects the type of hardware I have (here the type of the cpu-built-in gpui and tells me (via dmesg) which blobs are needed to satisfy the driver for the hardware it has detected. I will try that, moment please .. -- Regars Klaus
Re: [gentoo-user] need help with amdgpu driver
On 27.01.23 16:05, Klaus Dittrich wrote: On 27.01.23 15:30, Julien Roy wrote: Klaus Dittrich writes: as I do not use a initrd or initramfs I am, as far as I know, forced to compile the driver amdgpu into the kernel, not as modules to be loaded. No, you can use modules even without an initrd. I looked at https://wiki.gentoo.org/wiki/Amdgpu#Unknown_firmware_blobs but I still do not know what name is relevant to the built-in-gpu of a AMD-7900X processor.(!?) Does this gpu really needs all these blobs of the list there? No, these blobs are given as examples. They vary per GPU models and in fact there are several hundred different blobs available: ls -l /lib/firmware/amdgpu | wc -l 479 So you have to figure out which ones you need. The easiest method is to let the kernel load them itself by having the driver built as a module, otherwise it may take several iterations of modifying the CONFIG_EXTRA_FIRMWARE value until you get it to work. Julien and Peter, now I (assume I) understand what you mean. The kernel needs the entries to CONFIG_EXTRA_FIRMWARE just for drivers to be compiled in and for modules just to reduce the seeking in /lib/firmware/amdgpu ? So when I set CONFIG_DRM_AMDGPU=m and then look at dmesg of the so compiled kernel it detects the type of hardware I have (here the type of the cpu-built-in gpui and tells me (via dmesg) which blobs are needed to satisfy the driver for the hardware it has detected. I will try that, moment please .. Julien and Peter, I got no errors or messages form dmesg saying that some blobs are missed. I got some console messsages written in an very big font- So I compiled the the kernel again with AMDGPU=y this time and now I got all the messages of the kernel boot in normal fonts (my screen is 3840x2160). dmesg: [0.666078] amdgpu :0d:00.0: amdgpu: Fetched VBIOS from VFCT [0.666079] amdgpu: ATOM BIOS: 102-RAPHAEL-008 [0.666084] [drm] VCN(0) decode is enabled in VM mode [0.666085] [drm] VCN(0) encode is enabled in VM mode [0.666087] amdgpu :0d:00.0: vgaarb: deactivate vga console [0.666089] amdgpu :0d:00.0: amdgpu: Trusted Memory Zone (TMZ) feature not supported [0.666091] amdgpu :0d:00.0: amdgpu: PCIE atomic ops is not supported [0.666299] [drm] vm size is 262144 GB, 4 levels, block size is 9-bit, fragment size is 9-bit [0.666303] amdgpu :0d:00.0: amdgpu: VRAM: 512M 0x00F4 - 0x00F41FFF (512M used) [0.666305] amdgpu :0d:00.0: amdgpu: GART: 1024M 0x - 0x3FFF [0.666307] amdgpu :0d:00.0: amdgpu: AGP: 267419648M 0x00F8 - 0x [0.666311] [drm] Detected VRAM RAM=512M, BAR=512M [0.666312] [drm] RAM width 128bits DDR5 [0.666327] [drm] amdgpu: 512M of VRAM memory ready [0.666329] [drm] amdgpu: 31782M of GTT memory ready. [0.666525] [drm] GART: num cpu pages 262144, num gpu pages 262144 [0.39] [drm] PCIE GART of 1024M enabled (table at 0x00F41FC0). [0.666963] amdgpu :0d:00.0: amdgpu: PSP runtime database doesn't exist [0.666967] amdgpu :0d:00.0: amdgpu: PSP runtime database doesn't exist [0.667073] [drm] Loading DMUB firmware via PSP: version=0x05000500 [0.668329] [drm] use_doorbell being set to: [true] [0.668408] [drm] Found VCN firmware Version ENC: 1.24 DEC: 2 VEP: 0 Revision: 0 [0.668411] amdgpu :0d:00.0: amdgpu: Will use PSP to load VCN firmware [0.691438] [drm] reserve 0xa0 from 0xf41e00 for PSP TMR [0.760009] amdgpu :0d:00.0: amdgpu: RAS: optional ras ta ucode is not available [0.767012] amdgpu :0d:00.0: amdgpu: RAP: optional rap ta ucode is not available [0.767016] amdgpu :0d:00.0: amdgpu: SECUREDISPLAY: securedisplay ta ucode is not available [0.767276] amdgpu :0d:00.0: amdgpu: smu driver if version = 0x0004, smu fw if version = 0x0005, smu fw program = 0, smu fw version = 0x00544fcc (84.79.204) [0.768927] [drm] Display Core initialized with v3.2.207! [0.769472] [drm] DMUB hardware initialized: version=0x05000500 [0.815836] amdgpu :0d:00.0: adding component (ops 0x827288f0) [0.816440] device: 'i2c-0': device_add [0.816442] bus: 'i2c': add device i2c-0 [0.843548] device: 'i2c-1': device_add [0.843549] bus: 'i2c': add device i2c-1 [0.843778] device: 'i2c-2': device_add [0.843778] bus: 'i2c': add device i2c-2 [0.843809] device: 'i2c-3': device_add [0.843810] bus: 'i2c': add device i2c-3 [0.88] [drm] kiq ring mec 2 pipe 1 q 0 [0.846850] [drm] VCN decode and encode initialized successfully(under DPG Mode). [0.847968] kfd kfd: amdgpu: Allocated 3969056 bytes on gart [0.848003] amdgpu: sdma_bitmap: 3 [0.848271] amdgpu: Virtual CRAT table created for GPU [0.848480] amdgpu: Topology: Add dGPU node [0x164e:0x1002] [0.848482] kfd kfd: amdgpu: added device 1002:164e [0.848489] amdgpu
Re: [gentoo-user] need help with amdgpu driver
Klaus, [ 0.760009] amdgpu :0d:00.0: amdgpu: RAS: optional ras ta ucode is not available [ 0.767012] amdgpu :0d:00.0: amdgpu: RAP: optional rap ta ucode is not available [ 0.767016] amdgpu :0d:00.0: amdgpu: SECUREDISPLAY: securedisplay ta ucode is not available It seems I made a step forward and I will try to get get X11 up next. yep, that is normal. The firmware for encrypted display connection is not released yet. Cheers, Björn
Re: [gentoo-user] Udev Problems
Solved it, the rules are simply not triggered till after the modules are manually loaded. https://forums.gentoo.org/viewtopic-p-8772411.html#8772411 On 1/20/23 00:23, gekret005 wrote: Hello gentoo-user, I'm cross-posting my issue from https://github.com/anyc/steam-overlay/issues/326#issuecomment-1386038107 which turned into a core issue with my system which is not specific to steam. It seems that udev is not loading some rules on my system, notably: /lib/udev/rules.d/99-fuse.rules and /lib/udev/rules.d/60-game-input.rules . Udev is at the sysinit run level with openrc, and I do not have any custom rules. Something weird though is that restarting udev once after reboot applies the fuse rule, and a second time applies the uinput rule. I tried debugging a bit by turning on debug in /etc/udev/udev.conf and rebuilding the initramfs, but I'm not sure if its logged in /var/log or what as I can't find any problems being reported. Does anyone have any ideas as to what is wrong with my udev exactly?
Re: [gentoo-user] Soft scrolling on framebuffer consoles - New version of the patch - with GPM handling.
Hello, Peter.
On Fri, Jan 27, 2023 at 12:24:41 +, Peter Humphrey wrote:
> On Thursday, 26 January 2023 20:28:36 GMT Alan Mackenzie wrote:
> --->8
> > Again, on any problems please let me know and I'll try to fix them. As
> > ever, there are no guarantees, etc., etc., etc. My only promise is that
> > there's no malicious code in the patch.
> Good news! Well, partly... :)
> I applied the new patch to 5.15.88 and it seems fine. I'll have to test it in
> use and let you know.
I have since found a few bugs in that patch. Mainly they're to do with
losing 18 lines[*] GPM-ability at the earliest boot messages, when
changing font size, and things like that.
[*] 18 lines is the difference between 49 lines (from an 11x22 font such
as ter-122n) and 67 lines (from an 8x16 font like lat1-16) which fit on
the screen.
I've also discovered that when CONFIG_LOGO (i.e. displaying Tux at boot
up) is enabled, all boot messages which preceded the Tuxes become
invisible to GPM, and they cannot be selected. I don't (yet) know why
this is happening, but the obvious workaround is to disable CONFIG_LOGO
in one's kernel configuration.
I've found yet another bug which it's taken me a few hours to determine
is nothing to do with me. It goes like this: boot up in an 11x22 font
such as ter-122n, and move the mouse on that screen. Run the command
setfont lat1-16, which will resize the existing text. The GPM mouse is
now restricted to the 174x49 rectangle in the top left of the screen.
This is the bug. To free it, switch to a different tty and move the
mouse there. On returning to the first tty, the mouse can now be moved
over the entire screen.
The cause of this bug is that GPM does not connect up with screen
resizing events. The only time it determines a tty's size is when it
detects the tty has been switched. Not a big bug, but somewhat
annoying.
> Patching 6.1.8 failed, though, whereas the previous 5.15.80-scroll.
> 20221212.diff succeeded:
I haven't actually looked at any versions except for 5.15.80 and 5.15.88
so far.
> # patch -p1 < /usr/local/src/5.15.80-GPM.20230126.diff
> patching file drivers/tty/vt/vt.c
> Hunk #37 succeeded at 4748 (offset -1 lines).
> Hunk #38 succeeded at 5049 (offset -1 lines).
> Hunk #39 FAILED at 5353.
> 1 out of 39 hunks FAILED -- saving rejects to file drivers/tty/vt/vt.c.rej
> patching file drivers/video/console/Kconfig
> Hunk #1 succeeded at 99 (offset 1 line).
> patching file drivers/video/fbdev/core/fbcon.c
> Hunk #1 succeeded at 3171 (offset 19 lines).
> patching file include/linux/console_struct.h
> Hunk #2 FAILED at 170.
> 1 out of 2 hunks FAILED -- saving rejects to file include/linux/
> console_struct.h.rej
> patching file include/linux/vt_kern.h
> Hunk #1 succeeded at 114 (offset -1 lines).
> I've attached the reject files.
Thanks for these! It looks like it'll probably be straightforward to
amend the patch for 6.1.8. Are you currently running 6.1.8 as your main
kernel?
Anyhow, I'll probably post another patch with corrections in the next
day or two. Thanks for the testing!
> --
> Regards,
> Peter.
> --- drivers/tty/vt/vt.c
> +++ drivers/tty/vt/vt.c
> @@ -5353,10 +5965,19 @@ EXPORT_SYMBOL_GPL(screen_glyph);
>
> u32 screen_glyph_unicode(const struct vc_data *vc, int n)
> {
> - struct uni_screen *uniscr = get_vc_uniscr(vc);
> + int y = n / vc->vc_cols, x = n % vc->vc_cols;
> + uint32_t *ln = vc->vc_uniscr_curr + y * vc->vc_cols;
>
> - if (uniscr)
> - return uniscr->lines[n / vc->vc_cols][n % vc->vc_cols];
> + if (vc->vc_uniscr_curr) {
> + if (ln >= vc_uniscr_buf_end(vc))
> + ln -= vc->vc_uniscr_char_size;
> +#ifdef CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK_GPM
> + ln -= vc->vc_softback_lines * vc->vc_cols;
> + if (ln < vc->vc_uniscr_buf)
> + ln += vc->vc_uniscr_char_size;
> +#endif
> + return ln[x];
> + }
> return inverse_translate(vc, screen_glyph(vc, n * 2), 1);
> }
> EXPORT_SYMBOL_GPL(screen_glyph_unicode);
> --- include/linux/console_struct.h
> +++ include/linux/console_struct.h
> @@ -170,7 +181,11 @@ struct vc_data {
> struct vc_data **vc_display_fg; /* [!] Ptr to var holding fg
> console for this display */
> struct uni_pagedir *vc_uni_pagedir;
> struct uni_pagedir **vc_uni_pagedir_loc; /* [!] Location of uni_pagedir
> variable for this console */
> - struct uni_screen *vc_uni_screen; /* unicode screen content */
> +#ifdef CONFIG_FRAMEBUFFER_CONSOLE_SOFT_SCROLLBACK_GPM
> + uint32_t *vc_uniscr_buf;/* Address of unicode screen content */
> + unsigned int vc_uniscr_char_size; /* Size of *vc-uniscr_buf in 32-bit
> chars */
> + uint32_t *vc_uniscr_curr; /* Pos of first char of (unscrolled)
> screen */
> +#endif
> /* additional information is in vt_kern.h */
> };
>
--
Alan Mackenzie (Nuremberg, Germany).
[gentoo-user] Last rites: app-admin/gkrellm & plugins
Michał Górny wrote: > # Michał Górny (2023-01-27) > # GKrellM and a variety of plugins. It's unmaintained for some time. > # Upstream homepage is gone, and the whole suite is collecting dust > # and patches. > # Removal on 2023-02-26. Bug #892251. > > [also eclass/gkrellm-plugin.eclass] > > acct-group/gkrellmd > acct-user/gkrellmd > app-admin/gkrellm > app-laptop/ibam > media-plugins/gkrellmpc > x11-plugins/bfm > x11-plugins/gkrellaclock > x11-plugins/gkrellfire > x11-plugins/gkrellkam > x11-plugins/gkrellm-bgchanger > x11-plugins/gkrellm-bluez > x11-plugins/gkrellm-countdown > x11-plugins/gkrellm-cpupower > x11-plugins/gkrellm-imonc > x11-plugins/gkrellmlaunch > x11-plugins/gkrellm-leds > x11-plugins/gkrellm-mailwatch > x11-plugins/gkrellmoon > x11-plugins/gkrellm-plugins > x11-plugins/gkrellm-radio > x11-plugins/gkrellmss > x11-plugins/gkrellm-trayicons > x11-plugins/gkrellm-vaiobright > x11-plugins/gkrellm-volume > x11-plugins/gkrellmwireless > x11-plugins/gkrellm-xkb > x11-plugins/gkrellshoot > x11-plugins/gkrellstock > x11-plugins/gkrellsun > x11-plugins/gkrelltop > x11-plugins/gkrellweather > x11-plugins/gkwebmon > x11-plugins/i8krellm > x11-themes/gkrellm-themes > I'm forwarding this from the gentoo-dev-announce mailing list. It's also on -dev as well. It seems the guy who originally came up with and maintained gkrellm sadly died a while back. From other replies I read on -dev, there is some changes coming that may make gkrellm no longer work. It has something to do with GTK-3 support. It's a bit over my head to be honest. :/ First, if someone can help keep this going, it seems to be available, if the license allows someone else to take it over or fork it maybe. I don't know code but I do use gkrellm and sure would miss it. I suspect even a proxy maintainer would keep this alive. I have no idea how complicated the code for this thing is. It may be easy, it may be really advanced. Second, if no one takes it over, what could be used in its place? I'll be honest, I don't know of anything that could replace it but I've never thought about looking either. I'm looking into app-admin category but don't see anything obvious to replace it. I've tried some KDE plasma stuff ages ago, I still prefer gkrellm. None of them I looked at comes even close. I'm sure I'm not the only one on this mailing list who uses gkrellm. This is sort of a heads up. Someone already a dev may take it up, they may not. Help may would save it. Either way, this is a notice of the current state and if needed, a discussion on what we can use in its place. Thanks. Dale :-) :-)
