#linux Bot Logged User list

Network: freenode
Modes: +NPRnrt
Last Seen: an hour ago
Topic: Welcome to #linux | Channel Rules: https://wiki.freenode.net/view/Linux| linux discussion and support | Every Linux distribution is welcome | Ask our AI a question. ai: query goes here.
#12
Rank
67
Users

Channel Log Archive for #linux

Prev
Next

* All times are UTC
Filtering by user: BADB172
Monday, February 26, 2024
[09:53:35] BADB172 hey! I'm trying to create simple init from scratch, it runs fine but I can only see log messages (printk) from kernel, is it documented somewhere what you have to do to take over the framebuffer console?
[09:54:03] BADB172 I've looked source code of agetty and mingetty and tried to do the same: open /dev/console or /dev/tty1, ioctl with TIOCSCTTY, dup twice and then sys_write to STDOUT_FILENO but there is no visible output
[09:54:40] BADB172 using /dev/fb0 works but even then fbcon still runs on the background, overwriting my graphics with it's blinking cursor - while I could patch fbcon to not do that but obviously that's not how it should work, so what's the official way to "take over the framebuffer console" from userspace?
[09:55:14] BADB172 I apologize if this is a stupid question but I can't find anything with Google and I've wasted so many days trying to get this to work :/
[09:58:53] BADB172 well, "wasted so many days" is a harsh way to put it, this is a fun project for me but being stuck on the same thing for days on end is less fun. if anyone can point me in the right direction I'd appreciate that a lot, thanks!
[10:13:44] BADB172 I am testing this out on Raspberry Pi 3B+, I currently have CONFIG_DRM=n because whenever I enable it I get no signal from HDMI after it starts the DRM/KMS driver (I have dtoverlay=vc4-kms-v3d and the correct .dtbo in overlays) and no workarounds from Google have worked (like video=HDMI-A-1:1920x in cmdline)
[10:15:21] BADB172 I really don't know enough about DRM to say if that's the correct behavior and I would need to do something in userspace but I assume it's not because the console should work with DRM too, right? like on my desktop there's i915drmfb which provides necessary things for the framebuffer console to work
[10:23:24] BADB172 I've seen many people say how fbdev/fbcon is really buggy 90s code and full of security issues, at some point there was kmscon but it never became a replacement in mainline. all that sounds like it might not be a good idea to start a new project relying on fbdev, even though I assume it DRM's fbdev emulation is not going to disappear anytime soon? fbcon/CONFIG_VT could become deprecated so maybe it's not a
[10:23:30] BADB172 good idea to depend on those.. is there a good documentation how to do what I want with DRM, why is DRM_IOCTL_SET_MASTER important/what does it do?
[10:27:19] BADB172 I assume there is a lot of other things to do than just DRM_IOCTL_SET_MASTER or? is the whole process documented somewhere so you don't have to spend the whole day educating me :D
[10:27:48] BADB172 I just want a simple way to draw pixels on the screen without pulling wayland and huge amount of libraries which I think shouldn't be needed for this
[10:31:54] BADB172 oh, I see. ideally I would like to make my code as portable as possible, embedded systems might not have any GPU, just some kind of CPU-based software rendering. would that still work with simpledrm or something like that or is this one of those use cases where framebuffer makes more sense?
[10:37:04] BADB172 yeah, framebuffer sounds like what I want as I don't really need acceleration or good performance, just a portable way to draw text or simple graphics on the screen. do you think I should worry about framebuffer support being removed in the future, because there was a lot of talk about how fbcon, fbdev etc is full of legacy and vulnerable code and should be replaced with something better? maybe it's best
[10:37:10] BADB172 to just use /dev/fb0 and not use any of the stuff in fbcon which provides text rendering with bitmap fonts etc?
[11:01:42] BADB172 aaabbb: that's reassuring to hear, thanks! I know you said you can't help with framebuffer but as you're obviously more experienced wrt working with kernel, where should I look to find documentation about this (telling kernel "don't draw console on the screen, I'm doing everything from now on"), this is one of the simplest things one could hope to do so I guess I must be looking at the wrong place
[11:10:58] BADB172 aaabbb: I'll try to read it again, I guess the problem is it's not necessarily how framebuffer works but how fbcon uses the framebuffer by default. I guess I could set loglevel so that nothing is output and then disable blinking cursor, but it seems like there should be a simpler way to just "disable_fb_console();" so I don't have to worry about it doing something like refreshing screen and messing with my
[11:11:04] BADB172 output because it's running in the background
[11:12:20] BADB172 yeah, after the boot is complete I want to disable the console that's on the screen and start drawing my own thing to the framebuffer without having to worry that kernel is trying to do something with the framebuffer too (like it currently does, e.g. it redraws the blinking cursor over my graphics or if new printk happens it will too overwrite my graphics etc)
[11:16:49] BADB172 I guess that ioctl to set it to KD_GRAPHICS is what I've been looking, I would like to have the console shown while booting so if there's any kind of errors it would show information about them but if everything goes alright then my application starts running and will have the framebuffer to itself
[11:17:34] BADB172 I'll try that, thank you very much! looks like my google-fu skills need some improving
[11:35:05] BADB172 well, at least that hides the cursor but printk messages are being rendered. for example when I plug USB device it will mess my graphics up until next redraw happens, ouch. this is quite a puzzle for such a simple thing!
[11:52:32] BADB172 aaabbb: cool, that did it, thanks! I was just surprised there is no single function to set console status to off, that would seem like the most logical API. but I guess interfacing with kernel isn't always simple :) fwiw sysrq messages still mess up my graphics but those are a really special case, after all user could issue magic sysrq command to halt the system or whatever so I'm not worried about that
[11:53:27] BADB172 and if needed I could disable those sysrq keys that are a problem, it's not an issue for me right now. thanks again, this is really great!
[11:53:37] BADB172 yeah it's no problem :)
Prev
Next