[OpenIndiana-discuss] What's HASWELL support like on OI?

[Chris]

On 2021-01-28 22:18, Toomas Soome via openindiana-discuss wrote:
>> On 29. Jan 2021, at 07:48, Chris <oidev at bsdos.info> wrote:
>> 
>> On 2021-01-28 19:48, Gary Mills wrote:
>>> On Thu, Jan 28, 2021 at 05:35:38PM -0800, Chris wrote:
>>>> I'm trying to find some combination of hardware that will
>>>> produce reasonable performance at the console.
>>> By console, do you mean the raw console without a window manager?  If
>>> that's the case, it's no wonder that you are finding it slow.  Most
>>> people never see this, except during boot.  The raw console is known
>>> to be quite slow.  It's never been a problem because the terminal
>>> windows you get with a window manager are quite fast.  I have five
>>> low-end systems with a variety of video cards all running OI here.
>>> All I ever did was to do the initial install from the live USB image,
>>> and do updates afterwards with the pkg command.
>> Well *that's* depressing. Hmm. I guess my first task is going to be
>> *fixing* that. Frustrating; as I do a great deal of my initial work
>> from the console. Maybe I'm spoiled, because the (Free)BSD console(s)
>> are great. I can CTRL+ALT+F(1-12) for a new session, and attack
>> several different tasks simultaneously.
>> Guess I'm going to have to build all that into OI. Looks like OI uses
>> wcons. I'll see if I can coerce syscons(4) to replace it. Unless
>> someone else has a better idea/option. :-)
>> 
>> Thanks for taking the time to reply, Gary. Greatly appreciated!
>> 
>> —Chris
>> 
> 
> 
> You do not really want to start with replacing console with syscons, syscons
> itself is already obsolete and freebsd got itself in situation with two 
> competing
> (and broken in parts) console implementations:)
> 
> For virtual consoles, you want to check VT(7I), I do not know why we do not 
> enable
> vt’s bt default:
> 
> tsoome at beastie:~$ svcs -a | grep vt
> disabled       11:34:57 svc:/system/vtdaemon:default
> disabled       11:34:57 svc:/system/console-login:vt2
> disabled       11:34:57 svc:/system/console-login:vt3
> disabled       11:34:57 svc:/system/console-login:vt4
> disabled       11:34:57 svc:/system/console-login:vt5
> disabled       11:34:57 svc:/system/console-login:vt6
> 
> IMO this is a bug. In any case, there is not need to start with replacing 
> random
> components with another kind of random components when there is perfectly 
> good
> option about making existing components better;)
I fully agree that needless "competition* should be avoided.
However for production, I exclusively use Nvidia adapters, as there is far 
too
much overhead attempting to use AMD/radeon/intel on FreeBSD. They work very
inconsistently between brands, and between console vs Graphics/X(org). Most 
all
of this is simply the churn adapting Linux graphics to FreeBSD. In fact after
~2yrs. I am still unable to CTRL+ALT+F1 from X with anything but an Nvidia
adapter. In part because using an Nvidia adapter I simply add kern.vty=sc
to loader.conf(5) and I'm done. X works && so do all the consoles. I can't
say the same for the other video adapters. They all require vt(4) which is as
yet still immature, and incomplete as compared to syscons(2) (sc). The font
handling is poor. Copy Paste at the console is inconsistent && largely
impossible. Character mode is almost unusable. Mode switching is also wonky.
As it is, it is almost exclusively limited to Graphics mode, Which is fine
if you live in X. But if you're already in X, you don't need it.
My experience(s).

Thank you for taking the time to point out vt(4) lives in OI, Toomas. :-)

--Chris
> 
> rgds,
> toomas

-- 
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX