Am Sat, 15 Apr 2017 23:47:19 -0700
Kevin Oberman <rkober...@gmail.com> schrieb:

> On Sat, Apr 15, 2017 at 10:55 PM, O. Hartmann <ohartm...@walstatt.org>
> wrote:
> 
> > Am Sat, 15 Apr 2017 18:00:18 -0700
> > Conrad Meyer <c...@freebsd.org> schrieb:
> >  
> > > On Sat, Apr 15, 2017 at 1:21 PM, O. Hartmann <ohartm...@walstatt.org>  
> > wrote:  
> > > > Am Sat, 15 Apr 2017 20:03:50 +0000 (UTC)
> > > > Bruce Evans <b...@freebsd.org> schrieb:
> > > >  
> > > >> Author: bde
> > > >> Date: Sat Apr 15 20:03:50 2017
> > > >> New Revision: 316977
> > > >> URL: https://svnweb.freebsd.org/changeset/base/316977  
> > > >
> > > > There is a lot of development going on theses days for syscons. What's  
> > about vt()?  
> > > > vt() is considered broken for x11/nvidia-driver and vt() is considered  
> > a requirement  
> > > > when UEFI is boot scheme, isn't it?
> > > >
> > > > I'm just curious.  
> > >
> > > Hi O.,
> > >
> > > Bruce uses syscons and cares enough to improve it.  He likely does not
> > > care about UEFI and definitely does not care about vt.  I don't think
> > > there's anything wrong with that.  We can't force volunteers to work
> > > on things they are not interested in.
> > >
> > > Best,
> > > Conrad  
> >
> > Hello Conrad, happy easter.
> >
> > There is and was never intention to apply "force", it is a question as I'm
> > curious about
> > what's going on with vt() - no personally bound to B. Evans or anybody
> > else - I just took
> > the chance to comment/ask on that subject when I saw postings.
> >
> > Maybe not the right place to spread some thinkings.
> >
> > Regards,
> >
> > Oliver Hartmann
> >  
> 
> vt(4) is not a pleasant thing to look at. I am not implying that it is bad
> code or badly done. I am just saying that it is pretty gnarly and is not
> the sort of thing most enjoy dealing with. I got the distinct feeling that
> ray@ found the job much uglier than he anticipated  when he took the
> Foundation commission to write it. Since then it has been widely disparaged
> for the things that it does not do, but I am not aware that anyone has
> gotten further than looking at what is needed and then running far
> away.Some day someone (or some company) will get sufficiently inspired to
> either re-write if or add the missing features. I have no idea when that
> might happen, though.
> --
> Kevin Oberman, Part time kid herder and retired Network Engineer
> E-mail: rkober...@gmail.com
> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683

Hello Kevin.

So, what you say is: vt(4) is a kind of unwanted child, not to say: "part time 
orphaned"?
As far as I know, vt(4) is a requirement for UEFI/EFI booting. We do so were we 
can and
so we rely on vt(4). Please correct me if I'm wrong.

We also use vt(4) with pleasure for most of our servers's consoles - due to the 
great
improvements due to the higher resolution which makes it very easy to edit 
files/issue
commands/get results on the console. Especially in an experimental environment 
for
science, where a sophisticated infrastructure isn't available like graphical 
terminals
and so on.

Personally, I use FreeBSD even as workstation, apart from others, equipted with 
the
only-left working GPU vendor, nVidia, for high-performance graphics (Intel iGPU 
is fine
for laptops, but ... ), and here we run into a serious problem: on all nVidia 
driven
systems, with the newer drivers the console is garbage (on non-vt) when using 
sc(4) on
legacy booting boxes, with UEFI, vt(4) and nvidia produce a blank console. 

I've already
written a message to nVidia, but with no response until now for more than half 
a year and
the issue is present more than a year(!!!). As long as the nvidia kernel module 
is loaded,
the console is unusable and the nvidia module somehow blocks rebooting some of 
our
Fujitsu Celsius workstations. On a test box, I run 381.09 - the same problems.

By definition, vt(4) and nVidia driver has to be considered broken and this 
should be
reflected then in some message from the driver - but this isn't a subject for 
this list.

Thanks for your patience to read and answer.

Happy Easter,

Oliver Hartmann

-- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).

Attachment: pgpOC6WZeMtjC.pgp
Description: OpenPGP digital signature

Reply via email to