antiX-19-b1-full and tsplash tests needed.

Forum Forums News Announcements antiX-19-b1-full and tsplash tests needed.

This topic contains 62 replies, has 17 voices, and was last updated by masinick Jul 8-8:12 pm.

Viewing 15 posts - 46 through 60 (of 63 total)
  • Author
    Posts
  • #23532
    Forum Admin
    Avatar
    SamK

    Off Topic

    NoClue, you’re very opinionated. But that does not make you right.

    I’m not ‘very opinionated’ — I’m 100.001 % right (as mostly — experience shows but yes, you can’t know that and so, you’re excused).

    If I state something here, be it on a matter of design or like here, on a matter of energy efficiency — it’s based on solid and proven arguments — it’s NOT just ‘my opinion’.

    @noClue
    Opinionated does not refer to whether or not you are expressing your opinion. It refers to the manner in which you make your posts. It means Characterized by conceited assertiveness and dogmatism.
    ‘an arrogant and opinionated man’

    Ref: Opinionated
    https://www.lexico.com/en/definition/opinionated

    Your reply to seaken64 could not prove his point more clearly.

    You have been advised on more than one occasion to avoid making immoderate posts. Your behaviour is disrupting the forum and inconsiderate of other forum users. If you are unwilling to moderate your postings you should carefully consider whether the antiX forum is a suitable place for you.

    Have you stopped moderating here in antiX forum?!

    No we have not.

    We are a very small team. There are a few moderators who visit as time permits and some devs who try to mod and dev when they can. The more time we devs spend on matters like this the less we are able to spend on developing antiX.

    The approach to forum moderation has been one of laissez faire. It works well when members are respectful and express themselves moderately. The antiX forum used to be the most welcoming and considerate forum available. In my opinion it has become less so over the last five or six years. Members have become less tolerant, quicker to express anger, and make flippant remarks rather than engage in meaningful discussions.

    Attributing those changes to new members alone would be a mistake. It is regrettable that some long-term members reply to posts in a manner that raises the temperature by goading the poster. Keeping posts neutral in tone, and avoiding derision disguised as humour will help return the forum to being the most hospitable one available.

    The forum is a much better and more productive place when everyone is less immoderate, adopts self discipline, and respects the differing capabilities of other members.

    • This reply was modified 4 months ago by SamK.
    #23540
    Member
    Avatar
    zeh

    tsplash with splasht-f or splasht-s boot options runs without issues, except for a very minor one – it blinks twice (with a short interval between) and just before the system gets up and running it turns into a black screen for a moment. Not a problem for me; just reporting, since it seems something not supposed to happen, particularly the two blinks.

    #23547
    Member
    Avatar
    seaken64

    I apologize for contributing to being off topic.

    Do I understand correctly that the splasht is up for being the default? That is fine with me. But I have read other comments that text ‘scares’ the newbies. Maybe just an image, with a little hint in the lower section of the boot screen how to get the full text scroll version.

    Seaken64

    #23548
    Member
    AK-47
    AK-47

    If tsplash scares the newbies, then I’d hate to see what the rest of antiX will do to them. If anything I’d say a text-based splash makes antiX look more lightweight and conservative.

    Also like @zeh I get the blinks as well, although I didn’t report it because I thought it was normal since I’ve seen other OSes like Windows and OpenBSD do this.

    #23550
    Member
    Avatar
    seaken64

    Yesh, I don’t understand why text scares people. I held out for years with my DOS prompt before I finally got pulled in to a GUI. But if newbies are scared of text I guess we can figure out how to work around it. I see a lot of distros using a picture and spinning wheel or something similar. I personally like the scrolling text. splasht seems to be a hybrid.

    Seaken64

    #23649
    Member
    dgh
    dgh

    Intel Atom 330 w/ NVIDIA Ion (GeForce 9400m)
    Dell VGA 1280×1024
    works pretty well
    same results with splasht=f s & va

    text splash loads
    gets to 4 dots (start init)
    screen ‘goes black’ for maybe 1 second with a horizontal line @ 75-80% height (near the top)
    splash comes back with 6 dots (udev done)
    dots momentarily disappear as the 7th is filled

    hit reboot (or shutdown)
    normal antiX shutdown screen momentarily visible (again, maybe 1 second)
    text splash takes over

    with splasht=va, when rebooting/shutting down, the text cursor is momentarily visible beneath the word reboot/shutdown

    #23678
    Member
    dgh
    dgh

    I’ve tried in the past to add ascii art to the boot sequence, but my results were always poor

    I’m not much of a programmer, so I have only wondered; how difficult would it be to code/script something to load animated gifs, as text, during the startup / shutdown sequences? Or even just images, like in these libcaca examples.

    If someone made a splash screen with libcaca, they could call it cacasplash haha!

    #23699
    Forum Admin
    BitJam
    BitJam

    I’m reply to this post because it explains the expected behavior clearly (and a couple of unexpected things).

    text splash loads
    gets to 4 dots (start init)
    screen ‘goes black’ for maybe 1 second with a horizontal line @ 75-80% height (near the top)
    splash comes back with 6 dots (udev done)
    dots momentarily disappear as the 7th is filled

    This is what is expected except for the horizontal line. We “go black” for about a second to hide the screen jumping around and sometimes getting jumbled if/when udev loads a KMS video driver. Most distros don’t have to worry about this because they try to load the video driver from the initrd ASAP. But this can drastically increase the size of the live initrd which makes the iso file larger and also slows down the boot process.

    hit reboot (or shutdown)
    normal antiX shutdown screen momentarily visible (again, maybe 1 second)
    text splash takes over

    This is expected too. I do not know why we see tty1 for about a second. Maybe slim is doing that? IIUC the Xserver is configured to automatically switch to the tty that was enabled when X started. This is pretty cool because if tsplash is enabled then it switches to tty10 but if it was not enabled then it switches to tty1. If you boot into runlevel 3 and run “sudo service slim start” from tty2 then when you shut down from X you get switched back to tty2.

    with splasht=va, when rebooting/shutting down, the text cursor is momentarily visible beneath the word reboot/shutdown

    Good to know. I haven’t seen that here. I can try to get rid of it.

    I’d like to get rid of that brief visit to tty1 on shutdown but I don’t know what is causing it.

    The idea of tsplash is to *hide* the “scary” text with much less scary text. The Linux reviewer Dedoimedo has requested something like this since the release of the first version of MX, MX-14. IMO the jumping and jumbling that happens when a KMS video driver kicks in really should be covered up. But I’m not ready to bloat the system and slow the boot to hide it so I’ve settle for a blank screen.

    BTW: it might be possible to significantly reduce the amount of time the blank screen is show by using a udev rule that kicks in when the framebuffer changes. We already use such a rule to re-scale the console font and redraw the console decoration. Unfortunately I ran into several problems when I tried to do the same thing for tsplash. Currently each time tsplash needs to do something is is called anew usually using “openvt 10” to make sure it draws on tty10. I also tried using a fifo which is more efficient but ran into more problems with that. I decided that slow and stable was best for now. On tests I’ve done on a relatively fast machine, tsplash added about 0.3 seconds to the boot time. This is easy to measure with the start-t program which will tell you the number of seconds between when the kernel started and when a program started. I use
    start-t conky
    to measure how long it takes X to start.

    Anyway, there are a number of problems when I try to run tsplash from a udev rule. First, the udev rule always gets called twice. I don’t know why. I also include a third call at the end of the udev init.d script to restore the splash screen just in case the framebuffer was never changed so the udev rule is never called. These three calls overlap each other. That can be okay because openvt can act as a locking mechanism and if another program is using the tty you want to use then openvt will bow out. But then I ran into problems calling openvt from within a udev rule. Perhaps IO redirection would work instead:
    tsplash </dev/tty10 >/dev/tty10
    but I stopped experimenting and tried to get what I had into the beta so we could get feedback from people and to see how it worked on a variety of hardware systems. It’s been a journey of a lot of trial and error, filled with surprises.

    Fehlix and I created much larger console fonts yesterday going up to twice the previous maximum size. These would have made tsplash work well even on most high dpi displays set to maximum resolution. Unfortunately, the setfont program which is used to set the console font has a limit of 32 pixels and won’t load fonts larger than that. I just heard back from the setfont dev who said the font size limit of 32 is baked into the kernel. (sigh)

    The combination of the kernel limiting the console font size and the default of setting the console resolution as highest as possible is unfortunate. It means we are still going to struggle to make the consoles usable OOTB on high dpi systems.

    For the early boot before the KMS video driver kicks in, I think we have limited the resolution both in legacy boot and UEFI boot. For UEFI we put a list of resolutions to try in gfx_payload that are one half or one quarter of all the high dpi resolutions we could find, followed by the normal resolutions and finally “auto” in case none of the resolutions we listed match. I haven’t tested this but I think it works. I’d love to do the same thing in X windows. I even modified our make-org-conf program to make an xorg.conf that lists those same resolutions but the version of X in Buster (and maybe earlier) seems to ignore the resolution suggestions in xorg.conf. Maybe there is some other way of specifying a list of resolutions now.

    I find the situation maddening because it was totally obvious for many years that after stalling out at 1920×1080 for a while, the resolutions of laptops and other devices was going to increase. Yet most desktop programs, and now even the virtual consoles, are completely or nearly unusable at the those high resolutions. The kernel people, at long last finally added 32 pixel console fonts to the kernel but this was way too little way too late IMO.

    It is almost as if they are trying to make it as difficult as possible to have Linux boot into a working configuration OOTB on the first live boot. Almost every year they create new obstacles. OTOH, maybe there are ways around these problems that I don’t know about. If there was the equivalent of the grub2 gfx_payload variable that would allow us to set a list of acceptable resolutions followed by “auto” in case none of those resolutions matched then that would solve the problem. Likewise if there was a way to tell the KMS driver to use the current resolution that would also solve the problem. If we were allowed to have larger console fonts, that would at least solve the problem in the consoles.

    /rant

    Context is worth 80 IQ points -- Alan Kay

    #23700
    Member
    Avatar
    skidoo

    the udev rule always gets called twice

    a websearch found multiple Q/As stating “this typically indicates the rule is not specific enough. Try to make the rule more specific”

    #23707
    Member
    Xecure
    Xecure

    /rant

    I wouldn’t worry that much if I were you. I think it is already a superb way to display boot information and not alarm the “non-techy” user. If you can get it up and running on both live-environment and an installed system, that is all that matters.

    About the blanking, maybe display a little text at the bottom saying something like “Making changes. Please be patient” or “This may take some time. Don’t panic”, as with each system it will look different (more or less flashing, very short or long blank screen, etc. This also happens with other distros, nothing that anyone can do about it.

    #23709
    Forum Admin
    BitJam
    BitJam

    I wouldn’t worry that much if I were you. I think it is already a superb way to display boot information and not alarm the “non-techy” user. If you can get it up and running on both live-environment and an installed system, that is all that matters.

    Thank you! TBH, we have not ported it to the installed system yet.

    About the blanking, maybe display a little text at the bottom saying something like “Making changes. Please be patient” or “This may take some time. Don’t panic”,

    Anything we display will jump about and get jumbled. Putting text on the screen will defeat the blanking. A blank screen works because black is black so it does not matter if it jumps about and gets jumbled.

    To see what happens you could disable the blanking by using the cheat “bp=b9” to get a bash shell before init starts and then at the bash shell edit the file /etc/init.d/udev and comment out this line:
    [ "$DO_TSPLASH" -a -x $clear_ts ] && $clear_ts

    Context is worth 80 IQ points -- Alan Kay

    #23712
    Member
    Xecure
    Xecure

    Anything we display will jump about and get jumbled. Putting text on the screen will defeat the blanking. A blank screen works because black is black so it does not matter if it jumps about and gets jumbled.

    Understood. It was just an idea to avoid people panicking when the blanking happens (if at all). I just blurted out the first think that came to mind without knowing anything of how everything worked. Forgive my ignorance.

    To see what happens you could disable the blanking by using the cheat “bp=b9” to get a bash shell before init starts and then at the bash shell edit the file /etc/init.d/udev and comment out this line:

    [ “$DO_TSPLASH” -a -x $clear_ts ] && $clear_ts

    Thanks. It is good to know. I am not very concerned about the blanking, but this advice may be useful in the future.

    #23757
    Member
    Avatar
    skidoo

    the setfont program which is used to set the console font has a limit of 32 pixels and won’t load fonts larger than that. I just heard back from the setfont dev who said the font size limit of 32 is baked into the kernel. (sigh)

    The combination of the kernel limiting the console font size and the default of setting the console resolution as highest as possible is unfortunate. It means we are still going to struggle to make the consoles usable OOTB on high dpi systems.

    Bitjam, toward gaining access to larger font sizes…
    have you ruled out bundling fbterm + select fonts into the initrd and invoking fbterm early within init::main_wrapper() ?

    (the ruleout consideration is: would need to fallback in the event the stock antiX kernel has been replaced with a kernel which lacks fbcondecor)

    =====================

    For anyone unfamiliar with fbterm, check it out:

    from console:
    sudo apt install fbterm
    fbterm -s 48

    fbterm -v
    (lists available fonts)

    can specify background color, can multiplex (like screen or tmux) up to 10 windows…
    …and (what dgh asked) can apply a background image

    The only limitation of fbterm I’ve encountered is that wouldn’t start in SSH session, complaining ‘stdin is not an interactive tty’

    screenshot of a console running screen inside fbterm w/ Miles Davis backgound image:
    (no Xserver involved, this is a console environment)
    .

    #23857
    Member
    fungalnet
    fungalnet

    Tested and installed today on an AMD-phenom … it run like speeding Shkval torpedo.
    The only system that seems lighter and faster on the same machine is Void-musl.

    I am going to wait for the Deb 10 to be announced so I can elevate it to the new testing (11) system, to see what it is about, then off it goes to sid 🙂

    #24309
    Member
    Avatar
    PPC

    I tested splasht=f, in order to test the toram option, that I never tried before in antix19A1… I liked how it looks, enough information without overwhelming a newbies… I would only add a suggestion, change the text that is displayed during the reboot/power off sequence to something friendlier like “Please wait while antiX is rebooting” or something similar…
    P.S.- also out of topic- I noticed no speed increase using the toram option over using antiX live from my HD… I was expecting a way better performance- opening firefox and Libreoffice writer took about the same time…

    P.

Viewing 15 posts - 46 through 60 (of 63 total)

The topic ‘antiX-19-b1-full and tsplash tests needed.’ is closed to new replies.