On Tue, Aug 11, 2020 at 11:26 AM <[email protected]> wrote:
> Send Users mailing list submissions to > [email protected] > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.dragonflybsd.org/mailman/listinfo/users > or, via email, send a message with subject or body 'help' to > [email protected] > > You can reach the person managing the list at > [email protected] > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Users digest..." > > > Today's Topics: > > 1. Re: can I use the display native resolution on vty0 as on any > other vty's using KMS ? (karu.pruun) > 2. Re: can I use the display native resolution on vty0 as on any > other vty's using KMS ? (Jasse Jansson) > 3. Re: can I use the display native resolution on vty0 as on any > other vty's using KMS ? (nacho Lariguet) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Tue, 11 Aug 2020 11:18:34 +0300 > From: "karu.pruun" <[email protected]> > To: nacho Lariguet <[email protected]> > Cc: dragonFlyBSD user list <[email protected]> > Subject: Re: can I use the display native resolution on vty0 as on any > other vty's using KMS ? > Message-ID: > <CADdF=MK= > [email protected]> > Content-Type: text/plain; charset="UTF-8" > > Hello > > > Is it possible right now to end up in a pre-DRM situation by default ? > > IIRC kern.kms_console now defaults to 1 (don't know since when it does). > > The terminology here is a little confusing. I used pre-drm to mean > "until a drm driver (i915 or radeon) is loaded". Let me try to clarify > booting. > > The first screen with the boot menu is displayed by the loader. The > kernel modules to load by the loader are given in > > /boot/loader.conf > > However, the official advice is that the loader load the absolute > required minimum of kernel modules. For instance, my loader.conf has > no modules. This is because memory is tight at that early stage. If > you include, e.g. a drm driver, i915 or radeon, then the kernel will > most likely crash at boot. > > The official advice is to load modules later by placing them in > /etc/rc.conf, for instance, > > i915_load="YES" > > I have all the required wlan, drm etc there. And you can also load the > drm modules manually on console using 'kldload i915'. > > This means that, for instance, if I choose to load the drm driver > manually then I'm in the pre-drm stage until I will have kldloaded it, > say, on console, manually. The copyright note (the "Regents" screen > you mention), this is the kernel starting to load. This is pre-drm, > there is no drm driver anywhere. This is either VGA or the UEFI > display. The terminology "kms_columns" is misleading; that variable is > read by the system to try to figure out column x row configuration, > but there is no drm driver anywhere. That same "kms_columns" is also > read later by the drm driver to set the column x row configuration. > > So long story short: it is all pre-drm until the drm driver is > literally kldloaded. > > The screen change you see when going from loader to kernel loading > (the copyright, "Regents" note), there is no resolution change. The > resolution is the same as on the loader screen, it has been set by > UEFI. What you notice though is the change of font size. Between these > two screens, the system has done the calculation described in the > previous email, set the new column x row configuration, which is > larger than what you have in the UEFI screen; but there is no change > in resolution. Or perhaps there is slight change since it tries to > allocate a buffer that covers most of the screen. > > I may have missed details, maybe someone can clarify more. > > Cheers > > Peeter > > -- > > On Tue, Aug 11, 2020 at 1:41 AM nacho Lariguet <[email protected]> wrote: > > > > On Mon, 10 Aug 2020 14:37:14 +0300 > > "karu.pruun" <[email protected]> wrote: > > > > I'm attaching the output of "gop list" as mentioned before. > > > > You can clearly see that it boots straight to 1920x1200 right from the > > liveCD. So uEFI is informing 1920x1200 capability without any doubt. > > > > When it gets to the REGENTS message, it switches to a lower resolution. > > > > PS: I keep forgetting to CC the users list: sorry to reply twice Peeter > > > > > Hello > > > > > > I should clarify that when you load the drm driver (i915 or radeon, as > > > root on the console using 'kldload i915' or 'kldload radeon') the > > > initial buffer restriction does not apply any more. The drm drivers > > > allocate their own framebuffers, so all ttyv-s will have the same > > > column x row configuration. > > > > > > In the pre-drm situation, as explained earlier, the system tries to > > > work out an optimal column x row configuration based on the > > > information it gets from BIOS or UEFI. In the case of BIOS, you get > > > VGA modes; we don't have VESA at the moment, yet, if I'm correct. In > > > the case of UEFI, the system gets the resolution from UEFI and then > > > tries to work out the best column x row configuration under the > > > restriction that it must be max 160 column x 50 rows, font width is 8 > > > and the final configuration must preserve font scaling. For instance, > > > on my laptop this works out precisely as described: > > > > > > - UEFI tells the resolution is 1680x1050 (X x Y) > > > - Font width is 8 > > > - 1680 / 8 = 210, too large > > > - increase font width x 2 > > > - 1680 / 16 = 105, yes under 160 > > > - 1050 / 32 (font height is 16) = 32.8, round to nearest int, this is > > > 32; yes it's under 50 > > > - final setup: 105x32 > > > > > > The 105x32 is exactly what I get by default on my laptop if I set no > > > loader variables. > > > > > > I am not sure what if anything has changed between DragonFly 5.4 and > > > master. The syscons driver I believe is exactly the same. The BIOS and > > > UEFI setups would give different results though. > > > > > > I suggest you try to calculate the column x row configuration as > > > described above. In UEFI setup, you can see the modes as follows: at > > > boot, go to boot prompt (press '9'), and then do 'gop list' to see > > > what modes UEFI gives you. You can set the mode there too. (Give 'gop' > > > to see the command.) Enter 'boot' to continue booting. I guess you can > > > set the desired mode by default via a boot loader variable; but I > > > don't know what it would be. > > > > > > The graphical target etc stuff is linux speak, and probably systemd; > > > it has no relevance at all for DragonFly. > > > > > > Hope this helps. > > > > > > Peeter > > > > > > -- > > > > > > On Mon, Aug 10, 2020 at 1:33 AM nacho Lariguet <[email protected]> > wrote: > > > > > > > > On Sun, 9 Aug 2020 13:53:22 -0700 > > > > Jonathan Engwall <[email protected]> wrote: > > > > > > > > > On Sun, Aug 9, 2020, 12:00 PM <[email protected]> > wrote: > > > > > > > > > > > Send Users mailing list submissions to > > > > > > [email protected] > > > > > > > > > > > > To subscribe or unsubscribe via the World Wide Web, visit > > > > > > http://lists.dragonflybsd.org/mailman/listinfo/users > > > > > > or, via email, send a message with subject or body 'help' to > > > > > > [email protected] > > > > > > > > > > > > You can reach the person managing the list at > > > > > > [email protected] > > > > > > > > > > > > When replying, please edit your Subject line so it is more > specific > > > > > > than "Re: Contents of Users digest..." > > > > > > > > > > > > > > > > > > Today's Topics: > > > > > > > > > > > > 1. Re: can I use the display native resolution on vty0 as on > any > > > > > > other vty's using KMS ? (nacho Lariguet) > > > > > > 2. how do I label (meaning adding a reminder caption) to any > > > > > > given BSD slice ? (nacho Lariguet) > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > > > > > > > > Message: 1 > > > > > > Date: Sat, 8 Aug 2020 18:06:14 -0300 > > > > > > From: nacho Lariguet <[email protected]> > > > > > > To: [email protected] > > > > > > Subject: Re: can I use the display native resolution on vty0 as > on any > > > > > > other vty's using KMS ? > > > > > > Message-ID: <20200808180614.66f67761@leonov> > > > > > > Content-Type: text/plain; charset=US-ASCII > > > > > > > > > > > > On Sat, 8 Aug 2020 11:26:35 -0700 > > > > > > Jonathan Engwall <[email protected]> wrote: > > > > > > > > > > > > > Your picture looks to me like the standard "UNIX multi-user > mode" perhaps > > > > > > > you should select a graphical target somehow. Are making a > multi-head > > > > > > boot, > > > > > > > or bringing up each tty simultaneously? > > > > > > > Jonathan Engwall > > > > > > > > > > > > ... standard "UNIX multi-user mode" ... sure: do I did try/ask > for > > > > > > anything else ? > > > > > > > > > > > > I'm afraid I'm not following > > > > > > > > > > > > > > > > Your photo shows the BSD/UNIX default to boot to a root system > > > > > administrator account. To change this you will need to boot to a > graphical > > > > > target, or launch a multi head, or something relevant to what you > are doing. > > > > > I don't know what you are doing. Maybe puppet would work for you? > > > > > Jonathan Engwall > > > > > > > > OK. Let me be more clear. > > > > > > > > I want to start using dragonFly ... daily. > > > > > > > > So the first step is to install it on the hardware that for whatever > reasons > > > > I currently have, get it running without major issues, and last but > not least, > > > > set a working environment that suits my needs, which ends in the > following fact: > > > > > > > > What I want is dragonFly running ... WITHOUT X11 ! > > > > > > > > I just want to develop and work with/on the system console, which in > our case, > > > > happens to be syscons since we still don't have vt/wcons/whatever > which means > > > > no native UTF-8 console for the time being. > > > > > > > > I feel comfortable working/developing without a major stack like X > because: > > > > > > > > - I'm learning BSD and the best way to learn something like this is > bottom to top > > > > not the other way around. This is exactly what I've done with > arch-linux some years > > > > ago, I just installed a barebones system and from then on I kept > learning and > > > > needless to say I learned a lot of thinks of linux inner workings > which I doubt > > > > I could have learned with the zillion packages required by X and any > given desktop > > > > environment with all their complexity and all the duplicacte > functionality. Prior > > > > to start using linux I developed for many many years on, yes, > Microsoft products > > > > and whatnot. Eventually moving to linux was so alien that I wanted > to start, I say > > > > it again: bottom to top, not the other way around. > > > > > > > > - That said, I eventually want to move my primary workstation to > dragonFly and a > > > > couple of servers, and I decided, wisely or not, that I want to move > one server > > > > first because the server won't need X etc etc and albeit being a > file/web server > > > > to begin with, it will give me a working environment so I can start > coding in BSD, > > > > meaning primarily C. > > > > > > > > - Everything I need to code do not requires X at all: just a working > system console. > > > > I learned to use VIM in the past few years and feels quite > comfortably with it > > > > meaning I totally customized it (even I coded many syntax files from > scratch), and > > > > in my arch linux console environment I have everything I want to. > > > > > > > > That will give you a detailed overview of what I am after with > dragonFly. > > > > > > > > I need a couple of things: > > > > > > > > - digital video at max resolution: 1920x1200 in my case ... got it > on my test-bed > > > > desktop and will attempt to get it running on my PowerEdge servers > in a couple of > > > > days I guess. > > > > > > > > - a working US international keyboard layout (us-acentos) ... still > not working > > > > > > > > - a UTF-8 native console ... I know I should give up on this if I > want to use this OS > > > > > > > > - a custom script in CSH to execute after booting a liveCD that > formats/installs/ > > > > configures everything as needed ... almost done, testing it right > now. > > > > > > > > From there on I'm planing to use what for whatever reasons I am > currently using in arch: > > > > > > > > - BIND > > > > - nginx > > > > - postgreSQL > > > > > > > > Nothing special, all are in dPorts and I can customize and recompile > them as needed. > > > > > > > > WHEN I get this server working I will start fiddling with X11 on my > future BSD workstation. > > > > > > > > Sorry if this answer was a bit long but I hope you'll understand > where I am standing > > > > right now. > > > > > > > > > I don't know what you are doing. Maybe puppet would work for you? > > > > > > > > I'll eventually get it running with/without your support. > > > > > > > > Thanks for your advice, and I mean it. > > > > > > > > PS: You will note that I am asking a lot of questions on the mailing > list, I read the man > > > > pages, always, that won't mean that some thing can goes unnoticed to > me at any given time > > > > or that simply I just forgot about some x detail I read before, > there's a LOT to learn > > > > and the fact that I am asking is because I am a NEWBIE to BSD in > general and I want to > > > > learn, nothing out of the ordinary I guess. If that irritates you > just ignore me. I will > > > > be fine. > > > > > > > > > > > > > > > > > > > > > > ------------------------------ > > > > > > > > > > > > Message: 2 > > > > > > Date: Sun, 9 Aug 2020 15:04:42 -0300 > > > > > > From: nacho Lariguet <[email protected]> > > > > > > To: dragonFlyBSD user list <[email protected]> > > > > > > Subject: how do I label (meaning adding a reminder caption) to > any > > > > > > given BSD slice ? > > > > > > Message-ID: <20200809150442.7f5bc89d@leonov> > > > > > > Content-Type: text/plain; charset=US-ASCII > > > > > > > > > > > > ie: the "label:" field shown under the "diskid:" one with > disklabel64 > > > > > > > > > > > > It seems there is no switch (maybe -l) on disklabel64 (when > using -w) to > > > > > > label a slice. > > > > > > > > > > > > eg: > > > > > > > > > > > > # /dev/da0s1: > > > > > > # > > > > > > # Calculated informational fields for the slice: > > > > > > # > > > > > > # boot space: 1044480 bytes > > > > > > # data space: 175691776 blocks # 171574.00 MB (179908378624 > bytes) > > > > > > # > > > > > > # NOTE: The partition data base and stop are physically > > > > > > # aligned instead of slice-relative aligned. > > > > > > # > > > > > > # All byte equivalent offsets must be aligned. > > > > > > # > > > > > > diskid: af1b4686-d85d-11ea-9373-012324e2aca4 > > > > > > label: ... HOW TO SET THIS ONE ? > > > > > > boot2 data base: 0x000000001000 > > > > > > partitions data base: 0x000000100000 > > > > > > partitions data stop: 0x0029e3700000 > > > > > > backup label: 0x0029e37ff000 > > > > > > total size: 0x0029e3800000 # 171576.00 MB > > > > > > alignment: 4096 > > > > > > display block size: 1024 # for partition display and edit > only > > > > > > > > > > > > 16 partitions: > > > > > > # size offset fstype fsuuid > > > > > > a: 1048576 0 4.2BSD # 1024.000MB > > > > > > d: 33554432 1048576 HAMMER2 # 32768.000MB > > > > > > e: 134217728 34603008 HAMMER2 # 131072.000MB > > > > > > f: 6871040 168820736 HAMMER2 # 6710.000MB > > > > > > a-stor_uuid: eb61372a-d85d-11ea-9373-012324e2aca4 > > > > > > d-stor_uuid: eb613733-d85d-11ea-9373-012324e2aca4 > > > > > > e-stor_uuid: eb613739-d85d-11ea-9373-012324e2aca4 > > > > > > f-stor_uuid: eb61373e-d85d-11ea-9373-012324e2aca4 > > > > > > > > > > > > > > > > > > ------------------------------ > > > > > > > > > > > > Subject: Digest Footer > > > > > > > > > > > > _______________________________________________ > > > > > > Users mailing list > > > > > > [email protected] > > > > > > http://lists.dragonflybsd.org/mailman/listinfo/users > > > > > > > > > > > > > > > > > > ------------------------------ > > > > > > > > > > > > End of Users Digest, Vol 96, Issue 10 > > > > > > ************************************* > > > > > > > > > > > > > > > ------------------------------ > > Message: 2 > Date: Tue, 11 Aug 2020 16:47:49 +0200 > From: Jasse Jansson <[email protected]> > To: [email protected] > Subject: Re: can I use the display native resolution on vty0 as on any > other vty's using KMS ? > Message-ID: <[email protected]> > Content-Type: text/plain; charset=utf-8; format=flowed > > > On 2020-08-11 10:18, karu.pruun wrote: > > Hello > > > >> Is it possible right now to end up in a pre-DRM situation by default ? > >> IIRC kern.kms_console now defaults to 1 (don't know since when it does). > > The terminology here is a little confusing. I used pre-drm to mean > > "until a drm driver (i915 or radeon) is loaded". Let me try to clarify > > booting. > > > > The first screen with the boot menu is displayed by the loader. The > > kernel modules to load by the loader are given in > > > > /boot/loader.conf > > > > However, the official advice is that the loader load the absolute > > required minimum of kernel modules. For instance, my loader.conf has > > no modules. This is because memory is tight at that early stage. If > > you include, e.g. a drm driver, i915 or radeon, then the kernel will > > most likely crash at boot. > > > > The official advice is to load modules later by placing them in > > /etc/rc.conf, for instance, > > > > i915_load="YES" > > > > I have all the required wlan, drm etc there. And you can also load the > > drm modules manually on console using 'kldload i915'. > > > > This means that, for instance, if I choose to load the drm driver > > manually then I'm in the pre-drm stage until I will have kldloaded it, > > say, on console, manually. The copyright note (the "Regents" screen > > you mention), this is the kernel starting to load. This is pre-drm, > > there is no drm driver anywhere. This is either VGA or the UEFI > > display. The terminology "kms_columns" is misleading; that variable is > > read by the system to try to figure out column x row configuration, > > but there is no drm driver anywhere. That same "kms_columns" is also > > read later by the drm driver to set the column x row configuration. > > > > So long story short: it is all pre-drm until the drm driver is > > literally kldloaded. > > > > The screen change you see when going from loader to kernel loading > > (the copyright, "Regents" note), there is no resolution change. The > > resolution is the same as on the loader screen, it has been set by > > UEFI. What you notice though is the change of font size. Between these > > two screens, the system has done the calculation described in the > > previous email, set the new column x row configuration, which is > > larger than what you have in the UEFI screen; but there is no change > > in resolution. Or perhaps there is slight change since it tries to > > allocate a buffer that covers most of the screen. > > > > I may have missed details, maybe someone can clarify more. > > > > Cheers > > > > Peeter > > Things like this ought to be be added somewhere in the dragonfly wiki. > > > > > ------------------------------ > > Message: 3 > Date: Tue, 11 Aug 2020 15:26:38 -0300 > From: nacho Lariguet <[email protected]> > To: Peeter <[email protected]> > Cc: dragonFlyBSD user list <[email protected]> > Subject: Re: can I use the display native resolution on vty0 as on any > other vty's using KMS ? > Message-ID: <20200811152638.6addf9bd@leonov> > Content-Type: text/plain; charset=US-ASCII > > On Tue, 11 Aug 2020 11:18:34 +0300 > "karu.pruun" <[email protected]> wrote: > > > Hello > > > > > Is it possible right now to end up in a pre-DRM situation by default ? > > > IIRC kern.kms_console now defaults to 1 (don't know since when it > does). > > > > The terminology here is a little confusing. I used pre-drm to mean > > "until a drm driver (i915 or radeon) is loaded". Let me try to clarify > > booting. > > OK. Now it is crystal-clear what pre-DRM is. My guess was pre-DRM meaned > before we (I mean dragonFly) started using kms_console by default. > > > The first screen with the boot menu is displayed by the loader. The > > kernel modules to load by the loader are given in > > > > /boot/loader.conf > > Right. The only thing I always added there is kern.kms_columns=-1 > > > However, the official advice is that the loader load the absolute > > required minimum of kernel modules. For instance, my loader.conf has > > no modules. This is because memory is tight at that early stage. If > > you include, e.g. a drm driver, i915 or radeon, then the kernel will > > most likely crash at boot. > > > > The official advice is to load modules later by placing them in > > /etc/rc.conf, for instance, > > > > i915_load="YES" > > Right. Mine (rc.conf) has drm_load="yes" and radeon_load="yes". The > first is supposed to be automatically loaded by the second but I leave > it there to remind me of the process because it won't hurt at all. > > > I have all the required wlan, drm etc there. > > Me too. > > > And you can also load the drm modules manually on console using > > 'kldload i915'. > > Right. > > > This means that, for instance, if I choose to load the drm driver > > manually then I'm in the pre-drm stage until I will have kldloaded it, > > say, on console, manually. The copyright note (the "Regents" screen > > you mention), this is the kernel starting to load. This is pre-drm, > > there is no drm driver anywhere. This is either VGA or the UEFI > > display. The terminology "kms_columns" is misleading; that variable is > > read by the system to try to figure out column x row configuration, > > but there is no drm driver anywhere. That same "kms_columns" is also > > read later by the drm driver to set the column x row configuration. > > That's what mesmerizing me; suppose the following: > > I am booting @ 1920x1200 as set by the uEFI framebuffer code and then > while booting the kernel the REGENTS message follows (and seems lower > resolution due to the font scaling you mention but actually is at > 1920x1200) and then I end up at the root prompt still at 1920x1200 with > font scaling enabled @ 80x25 characters and without any drm driver at > all because when I booted I did not instructed the loader to use > anything out of the ordinary as advised by the man pages and/or the > handbook and/or whatever, and then, and only then I manually load the > DRM drivers with kldload drm and kldload radeon and when I issue > kldstat it shows them correctly loaded and then I do vidcontrol -i mode > on ttyv0 and it shows ONLY 80x25 while ttyv>=1 shows 240x75. In this > case I did not booted with the DRM drivers but I am still ending with > ttyv0 limited to less characters on the screen than the ones available > AFTER DRM was loaded post-boot the way is advised/intended to. > > Summarizing: > > - I boot the liveCD via uEFI without touching the boot loader options > > - kldload drm; > - kldload radeon; > - kldstat; ### shows radeon loaded and '[DRM] radeon' shows up in dmesg > > - vidcontrol -f 8x16 iso15-thin-8x16; > - vidcontrol -i mode; ### shows 80x25 > > - sysctl kern.kms_console; ### not found > - sysctl kern.kms_columns; ### not found > ### they are not even mentioned in the syscontrol man page > - sysctl kern.kms_columns=-1; ### unable to: unknown OID > > So, how do I instruct a running OS to switch to max columns now ? > > > So long story short: it is all pre-drm until the drm driver is > > literally kldloaded. > > > > The screen change you see when going from loader to kernel loading > > (the copyright, "Regents" note), there is no resolution change. The > > resolution is the same as on the loader screen, it has been set by > > UEFI. What you notice though is the change of font size. Between these > > two screens, the system has done the calculation described in the > > previous email, set the new column x row configuration, which is > > larger than what you have in the UEFI screen; but there is no change > > in resolution. Or perhaps there is slight change since it tries to > > allocate a buffer that covers most of the screen. > > > > I may have missed details, maybe someone can clarify more. > > I do really appreciate (your time and) your replies because they have a > lot of content to begin with. > > I also have to state that, what I was previously doing fiddling with the > boot loader options in order to get early-KMS start (as it is called in > linux) is because it didn't occurred to me I was ending in a 80x25 console > at 1920x1200 with font scaling enabled, to me it seemed like a standard > VGA screen, my fault, absolutely my fault. Although it will be nice to > have dragonFly (or for the matter whatever OS for instance) booting at > the best possible resolution (because it is far easy to read the kernel > messages this way) I do not need/require early-KMS at all, I am really > fine booting as it is intended to without DRM ... PROVIDED I can later > change to max characters after loading everything DRM-related via rc.conf > > I think the only thing I need to accomplish this right now is to find a > way of setting: > > sysctl kern.kms_columns=-1; > that would evaluate to -1, I think you mean: sysctl kern.kms_columns -= 1; > > Am I right ? > > > Cheers > > > > Peeter > > > > -- > > > > On Tue, Aug 11, 2020 at 1:41 AM nacho Lariguet <[email protected]> > wrote: > > > > > > On Mon, 10 Aug 2020 14:37:14 +0300 > > > "karu.pruun" <[email protected]> wrote: > > > > > > I'm attaching the output of "gop list" as mentioned before. > > > > > > You can clearly see that it boots straight to 1920x1200 right from the > > > liveCD. So uEFI is informing 1920x1200 capability without any doubt. > > > > > > When it gets to the REGENTS message, it switches to a lower resolution. > > > > > > PS: I keep forgetting to CC the users list: sorry to reply twice Peeter > > > > > > > Hello > > > > > > > > I should clarify that when you load the drm driver (i915 or radeon, > as > > > > root on the console using 'kldload i915' or 'kldload radeon') the > > > > initial buffer restriction does not apply any more. The drm drivers > > > > allocate their own framebuffers, so all ttyv-s will have the same > > > > column x row configuration. > > > > > > > > In the pre-drm situation, as explained earlier, the system tries to > > > > work out an optimal column x row configuration based on the > > > > information it gets from BIOS or UEFI. In the case of BIOS, you get > > > > VGA modes; we don't have VESA at the moment, yet, if I'm correct. In > > > > the case of UEFI, the system gets the resolution from UEFI and then > > > > tries to work out the best column x row configuration under the > > > > restriction that it must be max 160 column x 50 rows, font width is 8 > > > > and the final configuration must preserve font scaling. For instance, > > > > on my laptop this works out precisely as described: > > > > > > > > - UEFI tells the resolution is 1680x1050 (X x Y) > > > > - Font width is 8 > > > > - 1680 / 8 = 210, too large > > > > - increase font width x 2 > > > > - 1680 / 16 = 105, yes under 160 > > > > - 1050 / 32 (font height is 16) = 32.8, round to nearest int, this is > > > > 32; yes it's under 50 > > > > - final setup: 105x32 > > > > > > > > The 105x32 is exactly what I get by default on my laptop if I set no > > > > loader variables. > > > > > > > > I am not sure what if anything has changed between DragonFly 5.4 and > > > > master. The syscons driver I believe is exactly the same. The BIOS > and > > > > UEFI setups would give different results though. > > > > > > > > I suggest you try to calculate the column x row configuration as > > > > described above. In UEFI setup, you can see the modes as follows: at > > > > boot, go to boot prompt (press '9'), and then do 'gop list' to see > > > > what modes UEFI gives you. You can set the mode there too. (Give > 'gop' > > > > to see the command.) Enter 'boot' to continue booting. I guess you > can > > > > set the desired mode by default via a boot loader variable; but I > > > > don't know what it would be. > > > > > > > > The graphical target etc stuff is linux speak, and probably systemd; > > > > it has no relevance at all for DragonFly. > > > > > > > > Hope this helps. > > > > > > > > Peeter > > > > > > > > -- > > > > > > > > On Mon, Aug 10, 2020 at 1:33 AM nacho Lariguet <[email protected]> > wrote: > > > > > > > > > > On Sun, 9 Aug 2020 13:53:22 -0700 > > > > > Jonathan Engwall <[email protected]> wrote: > > > > > > > > > > > On Sun, Aug 9, 2020, 12:00 PM <[email protected]> > wrote: > > > > > > > > > > > > > Send Users mailing list submissions to > > > > > > > [email protected] > > > > > > > > > > > > > > To subscribe or unsubscribe via the World Wide Web, visit > > > > > > > http://lists.dragonflybsd.org/mailman/listinfo/users > > > > > > > or, via email, send a message with subject or body 'help' to > > > > > > > [email protected] > > > > > > > > > > > > > > You can reach the person managing the list at > > > > > > > [email protected] > > > > > > > > > > > > > > When replying, please edit your Subject line so it is more > specific > > > > > > > than "Re: Contents of Users digest..." > > > > > > > > > > > > > > > > > > > > > Today's Topics: > > > > > > > > > > > > > > 1. Re: can I use the display native resolution on vty0 as > on any > > > > > > > other vty's using KMS ? (nacho Lariguet) > > > > > > > 2. how do I label (meaning adding a reminder caption) to any > > > > > > > given BSD slice ? (nacho Lariguet) > > > > > > > > > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > > > > > > > > > > > Message: 1 > > > > > > > Date: Sat, 8 Aug 2020 18:06:14 -0300 > > > > > > > From: nacho Lariguet <[email protected]> > > > > > > > To: [email protected] > > > > > > > Subject: Re: can I use the display native resolution on vty0 > as on any > > > > > > > other vty's using KMS ? > > > > > > > Message-ID: <20200808180614.66f67761@leonov> > > > > > > > Content-Type: text/plain; charset=US-ASCII > > > > > > > > > > > > > > On Sat, 8 Aug 2020 11:26:35 -0700 > > > > > > > Jonathan Engwall <[email protected]> wrote: > > > > > > > > > > > > > > > Your picture looks to me like the standard "UNIX multi-user > mode" perhaps > > > > > > > > you should select a graphical target somehow. Are making a > multi-head > > > > > > > boot, > > > > > > > > or bringing up each tty simultaneously? > > > > > > > > Jonathan Engwall > > > > > > > > > > > > > > ... standard "UNIX multi-user mode" ... sure: do I did try/ask > for > > > > > > > anything else ? > > > > > > > > > > > > > > I'm afraid I'm not following > > > > > > > > > > > > > > > > > > > Your photo shows the BSD/UNIX default to boot to a root system > > > > > > administrator account. To change this you will need to boot to a > graphical > > > > > > target, or launch a multi head, or something relevant to what > you are doing. > > > > > > I don't know what you are doing. Maybe puppet would work for you? > > > > > > Jonathan Engwall > > > > > > > > > > OK. Let me be more clear. > > > > > > > > > > I want to start using dragonFly ... daily. > > > > > > > > > > So the first step is to install it on the hardware that for > whatever reasons > > > > > I currently have, get it running without major issues, and last > but not least, > > > > > set a working environment that suits my needs, which ends in the > following fact: > > > > > > > > > > What I want is dragonFly running ... WITHOUT X11 ! > > > > > > > > > > I just want to develop and work with/on the system console, which > in our case, > > > > > happens to be syscons since we still don't have vt/wcons/whatever > which means > > > > > no native UTF-8 console for the time being. > > > > > > > > > > I feel comfortable working/developing without a major stack like X > because: > > > > > > > > > > - I'm learning BSD and the best way to learn something like this > is bottom to top > > > > > not the other way around. This is exactly what I've done with > arch-linux some years > > > > > ago, I just installed a barebones system and from then on I kept > learning and > > > > > needless to say I learned a lot of thinks of linux inner workings > which I doubt > > > > > I could have learned with the zillion packages required by X and > any given desktop > > > > > environment with all their complexity and all the duplicacte > functionality. Prior > > > > > to start using linux I developed for many many years on, yes, > Microsoft products > > > > > and whatnot. Eventually moving to linux was so alien that I wanted > to start, I say > > > > > it again: bottom to top, not the other way around. > > > > > > > > > > - That said, I eventually want to move my primary workstation to > dragonFly and a > > > > > couple of servers, and I decided, wisely or not, that I want to > move one server > > > > > first because the server won't need X etc etc and albeit being a > file/web server > > > > > to begin with, it will give me a working environment so I can > start coding in BSD, > > > > > meaning primarily C. > > > > > > > > > > - Everything I need to code do not requires X at all: just a > working system console. > > > > > I learned to use VIM in the past few years and feels quite > comfortably with it > > > > > meaning I totally customized it (even I coded many syntax files > from scratch), and > > > > > in my arch linux console environment I have everything I want to. > > > > > > > > > > That will give you a detailed overview of what I am after with > dragonFly. > > > > > > > > > > I need a couple of things: > > > > > > > > > > - digital video at max resolution: 1920x1200 in my case ... got it > on my test-bed > > > > > desktop and will attempt to get it running on my PowerEdge servers > in a couple of > > > > > days I guess. > > > > > > > > > > - a working US international keyboard layout (us-acentos) ... > still not working > > > > > > > > > > - a UTF-8 native console ... I know I should give up on this if I > want to use this OS > > > > > > > > > > - a custom script in CSH to execute after booting a liveCD that > formats/installs/ > > > > > configures everything as needed ... almost done, testing it right > now. > > > > > > > > > > From there on I'm planing to use what for whatever reasons I am > currently using in arch: > > > > > > > > > > - BIND > > > > > - nginx > > > > > - postgreSQL > > > > > > > > > > Nothing special, all are in dPorts and I can customize and > recompile them as needed. > > > > > > > > > > WHEN I get this server working I will start fiddling with X11 on > my future BSD workstation. > > > > > > > > > > Sorry if this answer was a bit long but I hope you'll understand > where I am standing > > > > > right now. > > > > > > > > > > > I don't know what you are doing. Maybe puppet would work for > you? > > > > > > > > > > I'll eventually get it running with/without your support. > > > > > > > > > > Thanks for your advice, and I mean it. > > > > > > > > > > PS: You will note that I am asking a lot of questions on the > mailing list, I read the man > > > > > pages, always, that won't mean that some thing can goes unnoticed > to me at any given time > > > > > or that simply I just forgot about some x detail I read before, > there's a LOT to learn > > > > > and the fact that I am asking is because I am a NEWBIE to BSD in > general and I want to > > > > > learn, nothing out of the ordinary I guess. If that irritates you > just ignore me. I will > > > > > be fine. > > > > > > > > > > > > > > > > > > > > > > > > > > ------------------------------ > > > > > > > > > > > > > > Message: 2 > > > > > > > Date: Sun, 9 Aug 2020 15:04:42 -0300 > > > > > > > From: nacho Lariguet <[email protected]> > > > > > > > To: dragonFlyBSD user list <[email protected]> > > > > > > > Subject: how do I label (meaning adding a reminder caption) to > any > > > > > > > given BSD slice ? > > > > > > > Message-ID: <20200809150442.7f5bc89d@leonov> > > > > > > > Content-Type: text/plain; charset=US-ASCII > > > > > > > > > > > > > > ie: the "label:" field shown under the "diskid:" one with > disklabel64 > > > > > > > > > > > > > > It seems there is no switch (maybe -l) on disklabel64 (when > using -w) to > > > > > > > label a slice. > > > > > > > > > > > > > > eg: > > > > > > > > > > > > > > # /dev/da0s1: > > > > > > > # > > > > > > > # Calculated informational fields for the slice: > > > > > > > # > > > > > > > # boot space: 1044480 bytes > > > > > > > # data space: 175691776 blocks # 171574.00 MB (179908378624 > bytes) > > > > > > > # > > > > > > > # NOTE: The partition data base and stop are physically > > > > > > > # aligned instead of slice-relative aligned. > > > > > > > # > > > > > > > # All byte equivalent offsets must be aligned. > > > > > > > # > > > > > > > diskid: af1b4686-d85d-11ea-9373-012324e2aca4 > > > > > > > label: ... HOW TO SET THIS ONE ? > > > > > > > boot2 data base: 0x000000001000 > > > > > > > partitions data base: 0x000000100000 > > > > > > > partitions data stop: 0x0029e3700000 > > > > > > > backup label: 0x0029e37ff000 > > > > > > > total size: 0x0029e3800000 # 171576.00 MB > > > > > > > alignment: 4096 > > > > > > > display block size: 1024 # for partition display and > edit only > > > > > > > > > > > > > > 16 partitions: > > > > > > > # size offset fstype fsuuid > > > > > > > a: 1048576 0 4.2BSD # 1024.000MB > > > > > > > d: 33554432 1048576 HAMMER2 # 32768.000MB > > > > > > > e: 134217728 34603008 HAMMER2 # 131072.000MB > > > > > > > f: 6871040 168820736 HAMMER2 # 6710.000MB > > > > > > > a-stor_uuid: eb61372a-d85d-11ea-9373-012324e2aca4 > > > > > > > d-stor_uuid: eb613733-d85d-11ea-9373-012324e2aca4 > > > > > > > e-stor_uuid: eb613739-d85d-11ea-9373-012324e2aca4 > > > > > > > f-stor_uuid: eb61373e-d85d-11ea-9373-012324e2aca4 > > > > > > > > > > > > > > > > > > > > > ------------------------------ > > > > > > > > > > > > > > Subject: Digest Footer > > > > > > > > > > > > > > _______________________________________________ > > > > > > > Users mailing list > > > > > > > [email protected] > > > > > > > http://lists.dragonflybsd.org/mailman/listinfo/users > > > > > > > > > > > > > > > > > > > > > ------------------------------ > > > > > > > > > > > > > > End of Users Digest, Vol 96, Issue 10 > > > > > > > ************************************* > > > > > > > > > > > > > > > > > > > ------------------------------ > > Subject: Digest Footer > > _______________________________________________ > Users mailing list > [email protected] > http://lists.dragonflybsd.org/mailman/listinfo/users > > > ------------------------------ > > End of Users Digest, Vol 96, Issue 16 > ************************************* >
