Re: console in 11.0-ALPHA4

[Maxim Sobolev]

P.S. Asynchronous nature of vt is also a poor excuse in my view. There are
plenty ways to do it asynchronously, while preserving updates order. It
should not be one-or-the-other deal.

On Thu, Jun 30, 2016 at 7:21 AM, Maxim Sobolev  wrote:

> Ed, I think this is bug, not a feature. People expect scrolling and
> updates to be smooth these days, the fact that we deliberately break it
> just signifies very weird preferences somebody made while developing the
> code. The fact that it "looks fine when scrolling stops" is no execuse IMHO.
>
> -Max
>
> On Thu, Jun 30, 2016 at 6:42 AM, Ed Schouten  wrote:
>
>> Hi Maxim,
>>
>> 2016-06-28 21:14 GMT+02:00 Maxim Sobolev :
>> > P.S. Just if somebody is interested in fixing those "fast scrolling text
>> > turns into garbage" display issues, here is some screenshots of one of
>> my
>> > 11-alpha3 systems captured with a camera at 120fps. As you can see text
>> > tears down quite badly.
>>
>> What happens is that rendering of vt(4) is done asynchronously. In
>> addition to the screen contents, vt(4) keeps track of a rectangular
>> area of the screen that needs to be updated. During every refresh, the
>> rendering thread extracts and resets the coordinates of the
>> rectangular area and redraws that area. It only holds a lock while
>> extracting the rectangle's coordinates; not when redrawing.
>>
>> This means that if you have a lot of updates and redrawing is slow,
>> you will get 'random' garbage on screen. Once output stops, the screen
>> contents get refreshed one final time, making everything look all
>> right again.
>>
>> --
>> Ed Schouten 
>> Nuxi, 's-Hertogenbosch, the Netherlands
>> KvK-nr.: 62051717
>>
>>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: console in 11.0-ALPHA4

[Maxim Sobolev]

Ed, I think this is bug, not a feature. People expect scrolling and updates
to be smooth these days, the fact that we deliberately break it just
signifies very weird preferences somebody made while developing the code.
The fact that it "looks fine when scrolling stops" is no execuse IMHO.

-Max

On Thu, Jun 30, 2016 at 6:42 AM, Ed Schouten  wrote:

> Hi Maxim,
>
> 2016-06-28 21:14 GMT+02:00 Maxim Sobolev :
> > P.S. Just if somebody is interested in fixing those "fast scrolling text
> > turns into garbage" display issues, here is some screenshots of one of my
> > 11-alpha3 systems captured with a camera at 120fps. As you can see text
> > tears down quite badly.
>
> What happens is that rendering of vt(4) is done asynchronously. In
> addition to the screen contents, vt(4) keeps track of a rectangular
> area of the screen that needs to be updated. During every refresh, the
> rendering thread extracts and resets the coordinates of the
> rectangular area and redraws that area. It only holds a lock while
> extracting the rectangle's coordinates; not when redrawing.
>
> This means that if you have a lot of updates and redrawing is slow,
> you will get 'random' garbage on screen. Once output stops, the screen
> contents get refreshed one final time, making everything look all
> right again.
>
> --
> Ed Schouten 
> Nuxi, 's-Hertogenbosch, the Netherlands
> KvK-nr.: 62051717
>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: console in 11.0-ALPHA4

[Ed Schouten]

Hi Maxim,

2016-06-28 21:14 GMT+02:00 Maxim Sobolev :
> P.S. Just if somebody is interested in fixing those "fast scrolling text
> turns into garbage" display issues, here is some screenshots of one of my
> 11-alpha3 systems captured with a camera at 120fps. As you can see text
> tears down quite badly.

What happens is that rendering of vt(4) is done asynchronously. In
addition to the screen contents, vt(4) keeps track of a rectangular
area of the screen that needs to be updated. During every refresh, the
rendering thread extracts and resets the coordinates of the
rectangular area and redraws that area. It only holds a lock while
extracting the rectangle's coordinates; not when redrawing.

This means that if you have a lot of updates and redrawing is slow,
you will get 'random' garbage on screen. Once output stops, the screen
contents get refreshed one final time, making everything look all
right again.

-- 
Ed Schouten 
Nuxi, 's-Hertogenbosch, the Netherlands
KvK-nr.: 62051717
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: console in 11.0-ALPHA4

[Maxim Sobolev]

P.S. Just if somebody is interested in fixing those "fast scrolling text
turns into garbage" display issues, here is some screenshots of one of my
11-alpha3 systems captured with a camera at 120fps. As you can see text
tears down quite badly. I am curious if it's some lack of proper ordering
of updates in the vt code itself or just some effect of CPU cache not being
disabled properly when accessing frame buffer. It might look like a minor
issue, but that what's our default console produces. I really think we can
do better than that in 2016. I don't have any VESA-capable system around to
verify that claim, but I am quite sure it was not the case with the old
sc(4) in the pixel mode.

https://postimg.org/image/3nz6rirdj/
https://postimg.org/image/fr4if32fr/
https://postimg.org/image/onfaj0t1z/

On Wed, Jun 22, 2016 at 4:21 AM, Ernie Luzar  wrote:

> Kurt Jaeger wrote:
>
>> Hi!
>>
>> If you want textmode like in the old days, add this line to
>>> /boot/loader.conf:
>>>
>>> hw.vga.textmode="1"
>>>
>>
>> If I do this on a laptop 10.3p5, sending the laptop to sleep with
>> zzz causes a crash (!), which is reproducable.
>>
>>
> submit a PR
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: console in 11.0-ALPHA4

[Ernie Luzar]

Kurt Jaeger wrote:

Hi!

If you want textmode like in the old days, add this line to 
/boot/loader.conf:


hw.vga.textmode="1"


If I do this on a laptop 10.3p5, sending the laptop to sleep with
zzz causes a crash (!), which is reproducable.



submit a PR
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: console in 11.0-ALPHA4

[Kurt Jaeger]

Hi!

> If you want textmode like in the old days, add this line to 
> /boot/loader.conf:
> 
> hw.vga.textmode="1"

If I do this on a laptop 10.3p5, sending the laptop to sleep with
zzz causes a crash (!), which is reproducable.

-- 
p...@opsec.eu+49 171 3101372 4 years to go !
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: console in 11.0-ALPHA4

[Maxim Sobolev]

Ed,

For once, we have pretty good VGL support in the libSDL, at least version
1.x has been tested and seems to be building/working fine with
sc(4)+vesa(4) on supported hardware/VMs.

http://libsdl.org/download-1.2.php

So pretty much any application built against SDL 1.2 library should work.
Unless it uses some specific X11 stuff directly that is.

For what it's worth, I also have direct vgl support in my pet project here:
https://github.com/sobomax/digger )

-Max

On Tue, Jun 21, 2016 at 6:29 AM, Ed Maste  wrote:

> On the topic of vgl(3) specifically, in October 2014 I wrote on this list:
>
> > vgl(3) is a graphics library for syscons(4) that provides some basic
> > graphics operations (e.g. some mode setting, bitmaps, boxes,
> > ellipses). Right now it does not support the newer vt(4) console.
> >
> > In order to help determine the priority of a porting effort to add
> > vt(4) support I'd like to better understand where vgl is being used
> > now. I'd be interested in hearing about both open source software
> > using vgl as well as proprietary or internal applications. So if
> > you're using vgl I'd appreciate a follow up (in private is fine) with
> > a brief description of your use case.
>
> That received exactly one private reply, where it was pointed out that
> dosbox is an example consumer. Nobody replied to say they actually use
> vgl(3).
>
> I will post a followup to -stable to ask the same question, but
> please, let me know if you use vgl(3) in open source or proprietary
> software.
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
>


-- 
Maksym Sobolyev
Sippy Software, Inc.
Internet Telephony (VoIP) Experts
Tel (Canada): +1-778-783-0474
Tel (Toll-Free): +1-855-747-7779
Fax: +1-866-857-6942
Web: http://www.sippysoft.com
MSN: sa...@sippysoft.com
Skype: SippySoft
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: console in 11.0-ALPHA4

[Maxim Sobolev]

P.S. On more of IMHO side, I think having simple built in console graphics
library is quite important in order for kids to actually explore FreeBSD
early. I remember learning my first computer in elementary, with only few
KB of RAM it had BASIC interpreter built in and could already do basic
graphics primitives with just few lines of code. And that's what we had
explored quite early in the learning process. Computers we are running on
today are literally million times more powerful that that, both hardware
and software-wise, still you should not need to install whole X11
monstrosity to write graphics version of "hello world".

In any case if somebody is to add vt(4) support into libvgl, I could
probably help with testing that as well as possibly porting it to SDL 2.0.
My reduction of interest to maintaining that support has been generally
caused by the vesa going out of scope gradually, but with vt it might
actually revive it by opening it up for getting it running on most today's
x86 hardware and smaller arm systems as well.

-Max

On Tue, Jun 21, 2016 at 11:33 AM, Maxim Sobolev 
wrote:

> Ed,
>
> For once, we have pretty good VGL support in the libSDL, at least version
> 1.x has been tested and seems to be building/working fine with
> sc(4)+vesa(4) on supported hardware/VMs.
>
> http://libsdl.org/download-1.2.php
>
> So pretty much any application built against SDL 1.2 library should work.
> Unless it uses some specific X11 stuff directly that is.
>
> For what it's worth, I also have direct vgl support in my pet project
> here: https://github.com/sobomax/digger )
>
> -Max
>
> On Tue, Jun 21, 2016 at 6:29 AM, Ed Maste  wrote:
>
>> On the topic of vgl(3) specifically, in October 2014 I wrote on this list:
>>
>> > vgl(3) is a graphics library for syscons(4) that provides some basic
>> > graphics operations (e.g. some mode setting, bitmaps, boxes,
>> > ellipses). Right now it does not support the newer vt(4) console.
>> >
>> > In order to help determine the priority of a porting effort to add
>> > vt(4) support I'd like to better understand where vgl is being used
>> > now. I'd be interested in hearing about both open source software
>> > using vgl as well as proprietary or internal applications. So if
>> > you're using vgl I'd appreciate a follow up (in private is fine) with
>> > a brief description of your use case.
>>
>> That received exactly one private reply, where it was pointed out that
>> dosbox is an example consumer. Nobody replied to say they actually use
>> vgl(3).
>>
>> I will post a followup to -stable to ask the same question, but
>> please, let me know if you use vgl(3) in open source or proprietary
>> software.
>> ___
>> freebsd-current@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org
>> "
>>
>>
>
>
> --
> Maksym Sobolyev
> Sippy Software, Inc.
> Internet Telephony (VoIP) Experts
> Tel (Canada): +1-778-783-0474
> Tel (Toll-Free): +1-855-747-7779
> Fax: +1-866-857-6942
> Web: http://www.sippysoft.com
> MSN: sa...@sippysoft.com
> Skype: SippySoft
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: console in 11.0-ALPHA4

[Ed Maste]

On the topic of vgl(3) specifically, in October 2014 I wrote on this list:

> vgl(3) is a graphics library for syscons(4) that provides some basic
> graphics operations (e.g. some mode setting, bitmaps, boxes,
> ellipses). Right now it does not support the newer vt(4) console.
>
> In order to help determine the priority of a porting effort to add
> vt(4) support I'd like to better understand where vgl is being used
> now. I'd be interested in hearing about both open source software
> using vgl as well as proprietary or internal applications. So if
> you're using vgl I'd appreciate a follow up (in private is fine) with
> a brief description of your use case.

That received exactly one private reply, where it was pointed out that
dosbox is an example consumer. Nobody replied to say they actually use
vgl(3).

I will post a followup to -stable to ask the same question, but
please, let me know if you use vgl(3) in open source or proprietary
software.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: console in 11.0-ALPHA4

[O. Hartmann]

On Mon, 20 Jun 2016 22:11:52 -0700
"Chris H"  wrote:

> On Mon, 20 Jun 2016 16:22:53 -0700 John Baldwin  wrote
> 
> > On Monday, June 20, 2016 04:54:11 PM Ernie Luzar wrote:  
> > > Ed Maste wrote:  
> > > > On 20 June 2016 at 14:29, Ernie Luzar  wrote:  
> > > >> I found the cause of this boot time message
> > > >> "vicontrol: setting cursor type: Inappropriate ioctl for device"
> > > >>
> > > >> In my rc.conf I had this statement
> > > >> vidcontrol -c blink -h 250
> > > >> From testing it seems that vt does not handle the "blink" option for
> > > >> causing the cursor to blink. Is there a vt option to enable cursor 
> > > >> blinking > >   
> > > > I've submitted two PRs for the issues you reported here:
> > > > Bug 210413 - vidcontrol -c  does not work with
> > > > vt(4) Bug 210415 - vidcontrol -h  does not work with vt(4)
> > > > (edit) 
> > > > There is currently no option to enable cursor blinking.  
> > > 
> > > 
> > > Further testing shows that:
> > > 
> > > 1. The rc.conf option screen saver "saver= " and the "blanktime= " 
> > > options work in vt for both text and graph modes.
> > > 
> > > 2. The cursor copy/paste does not work in vt text mode. It only works in 
> > > vt graph mode. vt needs to be fixed so copy/paste function also works in 
> > > text mode.
> > > 
> > > 3. Boot time splash screen does not work in vt at all no matter which 
> > > mode is enabled. Using this in loader.conf
> > > splash_bmp_load="YES"
> > > bitmap_name="/boot/splash.bmp"
> > > bitload_load="YES"
> > > 
> > > This works in 10.x. The splash screen function can not be allowed to be 
> > > removed from the base system just because vt can not handle it. This 
> > > also means any vt changes need to updated in the handbook section on 
> > > splash screen.
> > > 
> > > In conclusion, vt is not ready to replace the sc console driver yet. vt 
> > > needs to be fixed before becoming the default in 11.0. Using vt as the 
> > > default console driver effects every user. It completely changes the 
> > > FreeBSD experience. It's detrimental to the public relations and the 
> > > professional image of FreeBSD to publish the 11.0-RELEASE using vt in 
> > > its current condition. If time doesn't permit to get these vt things 
> > > fixed before publishing 11.0 then vt should not become the default 
> > > console driver.  
> > 
> > OTOH, if you use EFI, then you can't use sc(4).  You get no working console
> > with EFI (which is becoming more popular) if you use sc(4).  You also do
> > not get non-ASCII characters with sc(4), so you don't have a UTF-8 capable
> > console if you use sc(4).  You also do not have a working console after
> > loading the KMS drivers (either by starting X or via explicit kldload) when
> > using sc(4).  This affects just about every modern Intel system using an
> > Intel GPU (so more widespread than EFI even).
> > 
> > There are tradeoffs in both directions.  Neither console is a subset of the
> > other.  However, sc(4) is not really extendable to support the things it is
> > missing.  vt(4) is actively worked on, and patches for the features it lacks
> > that you need are certainly welcomed.  
> AMD, and ATI are also quite popular, as well as nVidia. In the case of
> nVidia, vt(4) is nearly as good as sc(4) on/in [U]EFI.

most recent nVidia BLOBs (starting with the separation of the kernel module in
nvidia-modset.ko and nvidia.ko kernel object modules) do not work properly
nor with sc(4), neither vt(4) on most recent CURRENT! See 

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=201340

With non-UEFI, die console is unusable due to some weird 1980s blocky-coloured
signs in 80x25 col/rows, with UEFI there is simply black screen when switching
to console - this is the fact as long the nvidia-modeset.ko is loaded. After
unloading, the problems disappear.

And by the way: at the moment nVidia's offering of a BLOB is the only, and THE
only way to provide acceptable support and performnce for recent and modern
GPUs. Since many people or those making decissions are not inclined to purchase
"old" but working stuff for a perspective of 3-5 years, a working console
seemes to me to be important.
 
> 
> I think the [original] point here was; for all that vt(4) intends to
> provide, it's just not ready for prime time, and as such, shouldn't
> be made default, just yet. :-)
> 
> --Chris
> > 
> > -- 
> > John Baldwin  
> 
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: console in 11.0-ALPHA4

[Maxim Sobolev]

For what it's worth: my two biggest grievances with the vt(4) vs. sc(4) is
the unordered updates in the graphics mode which makes watching quickly
scrolling text on something like virtual machine console funky and lack of
support in the libvgl(3). The latter I find particularly hard to explain,
since vt is supposed to be designed around graphics mode, so it should have
easier to interface that to userland. People built apps around those
interfaces, so unless we are going to replace libvgl with something else or
depreciate it, we better support both console backends in there.

-Max
On Jun 20, 2016 10:11 PM, "Chris H"  wrote:

> On Mon, 20 Jun 2016 16:22:53 -0700 John Baldwin  wrote
>
> > On Monday, June 20, 2016 04:54:11 PM Ernie Luzar wrote:
> > > Ed Maste wrote:
> > > > On 20 June 2016 at 14:29, Ernie Luzar  wrote:
> > > >> I found the cause of this boot time message
> > > >> "vicontrol: setting cursor type: Inappropriate ioctl for device"
> > > >>
> > > >> In my rc.conf I had this statement
> > > >> vidcontrol -c blink -h 250
> > > >> From testing it seems that vt does not handle the "blink" option for
> > > >> causing the cursor to blink. Is there a vt option to enable cursor
> > > >> blinking > >
> > > > I've submitted two PRs for the issues you reported here:
> > > > Bug 210413 - vidcontrol -c  does not work
> with
> > > > vt(4) Bug 210415 - vidcontrol -h  does not work with
> vt(4)
> > > > (edit)
> > > > There is currently no option to enable cursor blinking.
> > >
> > >
> > > Further testing shows that:
> > >
> > > 1. The rc.conf option screen saver "saver= " and the "blanktime= "
> > > options work in vt for both text and graph modes.
> > >
> > > 2. The cursor copy/paste does not work in vt text mode. It only works
> in
> > > vt graph mode. vt needs to be fixed so copy/paste function also works
> in
> > > text mode.
> > >
> > > 3. Boot time splash screen does not work in vt at all no matter which
> > > mode is enabled. Using this in loader.conf
> > > splash_bmp_load="YES"
> > > bitmap_name="/boot/splash.bmp"
> > > bitload_load="YES"
> > >
> > > This works in 10.x. The splash screen function can not be allowed to be
> > > removed from the base system just because vt can not handle it. This
> > > also means any vt changes need to updated in the handbook section on
> > > splash screen.
> > >
> > > In conclusion, vt is not ready to replace the sc console driver yet. vt
> > > needs to be fixed before becoming the default in 11.0. Using vt as the
> > > default console driver effects every user. It completely changes the
> > > FreeBSD experience. It's detrimental to the public relations and the
> > > professional image of FreeBSD to publish the 11.0-RELEASE using vt in
> > > its current condition. If time doesn't permit to get these vt things
> > > fixed before publishing 11.0 then vt should not become the default
> > > console driver.
> >
> > OTOH, if you use EFI, then you can't use sc(4).  You get no working
> console
> > with EFI (which is becoming more popular) if you use sc(4).  You also do
> > not get non-ASCII characters with sc(4), so you don't have a UTF-8
> capable
> > console if you use sc(4).  You also do not have a working console after
> > loading the KMS drivers (either by starting X or via explicit kldload)
> when
> > using sc(4).  This affects just about every modern Intel system using an
> > Intel GPU (so more widespread than EFI even).
> >
> > There are tradeoffs in both directions.  Neither console is a subset of
> the
> > other.  However, sc(4) is not really extendable to support the things it
> is
> > missing.  vt(4) is actively worked on, and patches for the features it
> lacks
> > that you need are certainly welcomed.
> AMD, and ATI are also quite popular, as well as nVidia. In the case of
> nVidia, vt(4) is nearly as good as sc(4) on/in [U]EFI.
>
> I think the [original] point here was; for all that vt(4) intends to
> provide, it's just not ready for prime time, and as such, shouldn't
> be made default, just yet. :-)
>
> --Chris
> >
> > --
> > John Baldwin
>
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
>
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: console in 11.0-ALPHA4

[Chris H]

On Mon, 20 Jun 2016 16:22:53 -0700 John Baldwin  wrote

> On Monday, June 20, 2016 04:54:11 PM Ernie Luzar wrote:
> > Ed Maste wrote:
> > > On 20 June 2016 at 14:29, Ernie Luzar  wrote:
> > >> I found the cause of this boot time message
> > >> "vicontrol: setting cursor type: Inappropriate ioctl for device"
> > >>
> > >> In my rc.conf I had this statement
> > >> vidcontrol -c blink -h 250
> > >> From testing it seems that vt does not handle the "blink" option for
> > >> causing the cursor to blink. Is there a vt option to enable cursor 
> > >> blinking > > 
> > > I've submitted two PRs for the issues you reported here:
> > > Bug 210413 - vidcontrol -c  does not work with
> > > vt(4) Bug 210415 - vidcontrol -h  does not work with vt(4)
> > > (edit) 
> > > There is currently no option to enable cursor blinking.
> > 
> > 
> > Further testing shows that:
> > 
> > 1. The rc.conf option screen saver "saver= " and the "blanktime= " 
> > options work in vt for both text and graph modes.
> > 
> > 2. The cursor copy/paste does not work in vt text mode. It only works in 
> > vt graph mode. vt needs to be fixed so copy/paste function also works in 
> > text mode.
> > 
> > 3. Boot time splash screen does not work in vt at all no matter which 
> > mode is enabled. Using this in loader.conf
> > splash_bmp_load="YES"
> > bitmap_name="/boot/splash.bmp"
> > bitload_load="YES"
> > 
> > This works in 10.x. The splash screen function can not be allowed to be 
> > removed from the base system just because vt can not handle it. This 
> > also means any vt changes need to updated in the handbook section on 
> > splash screen.
> > 
> > In conclusion, vt is not ready to replace the sc console driver yet. vt 
> > needs to be fixed before becoming the default in 11.0. Using vt as the 
> > default console driver effects every user. It completely changes the 
> > FreeBSD experience. It's detrimental to the public relations and the 
> > professional image of FreeBSD to publish the 11.0-RELEASE using vt in 
> > its current condition. If time doesn't permit to get these vt things 
> > fixed before publishing 11.0 then vt should not become the default 
> > console driver.
> 
> OTOH, if you use EFI, then you can't use sc(4).  You get no working console
> with EFI (which is becoming more popular) if you use sc(4).  You also do
> not get non-ASCII characters with sc(4), so you don't have a UTF-8 capable
> console if you use sc(4).  You also do not have a working console after
> loading the KMS drivers (either by starting X or via explicit kldload) when
> using sc(4).  This affects just about every modern Intel system using an
> Intel GPU (so more widespread than EFI even).
> 
> There are tradeoffs in both directions.  Neither console is a subset of the
> other.  However, sc(4) is not really extendable to support the things it is
> missing.  vt(4) is actively worked on, and patches for the features it lacks
> that you need are certainly welcomed.
AMD, and ATI are also quite popular, as well as nVidia. In the case of
nVidia, vt(4) is nearly as good as sc(4) on/in [U]EFI.

I think the [original] point here was; for all that vt(4) intends to
provide, it's just not ready for prime time, and as such, shouldn't
be made default, just yet. :-)

--Chris
> 
> -- 
> John Baldwin


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: console in 11.0-ALPHA4

[Kevin Oberman]

On Mon, Jun 20, 2016 at 6:01 PM, Ernie Luzar  wrote:

> John Baldwin wrote:
>
>> On Monday, June 20, 2016 04:54:11 PM Ernie Luzar wrote:
>>
>>> Ed Maste wrote:
>>>
 On 20 June 2016 at 14:29, Ernie Luzar  wrote:

> I found the cause of this boot time message
> "vicontrol: setting cursor type: Inappropriate ioctl for device"
>
> In my rc.conf I had this statement
> vidcontrol -c blink -h 250
> From testing it seems that vt does not handle the "blink" option for
> causing
> the cursor to blink. Is there a vt option to enable cursor  blinking
>
 I've submitted two PRs for the issues you reported here:
 Bug 210413 - vidcontrol -c  does not work
 with vt(4)
 Bug 210415 - vidcontrol -h  does not work with vt(4)
 (edit)

 There is currently no option to enable cursor blinking.

>>>
>>> Further testing shows that:
>>>
>>> 1. The rc.conf option screen saver "saver= " and the "blanktime= "
>>> options work in vt for both text and graph modes.
>>>
>>> 2. The cursor copy/paste does not work in vt text mode. It only works in
>>> vt graph mode. vt needs to be fixed so copy/paste function also works in
>>> text mode.
>>>
>>> 3. Boot time splash screen does not work in vt at all no matter which
>>> mode is enabled. Using this in loader.conf
>>> splash_bmp_load="YES"
>>> bitmap_name="/boot/splash.bmp"
>>> bitload_load="YES"
>>>
>>> This works in 10.x. The splash screen function can not be allowed to be
>>> removed from the base system just because vt can not handle it. This also
>>> means any vt changes need to updated in the handbook section on splash
>>> screen.
>>>
>>> In conclusion, vt is not ready to replace the sc console driver yet. vt
>>> needs to be fixed before becoming the default in 11.0. Using vt as the
>>> default console driver effects every user. It completely changes the
>>> FreeBSD experience. It's detrimental to the public relations and the
>>> professional image of FreeBSD to publish the 11.0-RELEASE using vt in its
>>> current condition. If time doesn't permit to get these vt things fixed
>>> before publishing 11.0 then vt should not become the default console driver.
>>>
>>
>> OTOH, if you use EFI, then you can't use sc(4).  You get no working
>> console
>> with EFI (which is becoming more popular) if you use sc(4).  You also do
>> not get non-ASCII characters with sc(4), so you don't have a UTF-8 capable
>> console if you use sc(4).  You also do not have a working console after
>> loading the KMS drivers (either by starting X or via explicit kldload)
>> when
>> using sc(4).  This affects just about every modern Intel system using an
>> Intel GPU (so more widespread than EFI even).
>>
>> There are trade offs in both directions.  Neither console is a subset of
>> the
>> other.  However, sc(4) is not really expendable to support the things it
>> is
>> missing.  vt(4) is actively worked on, and patches for the features it
>> lacks
>> that you need are certainly welcomed.
>>
>>
> This sounds like a integration design error. From your description of the
> hardware that vt is designed for and sc is designed for indicates the need
> for some code to be added to the boot process that inspects the hardware
> and decides whether vt or sc is to be launched. Or maybe bsdinstall should
> inspect the hardware and give the installer the option to select what
> console is best for his hardware. Just forcing this version of vt that
> lacks long time functions as the default console driver is not the
> professional way to handle such conflicts.
>
> I am at a lost to understand how any development administrator would
> approve making vt the default console driver in light of the standard
> functions missing from it. And furthermore what kind of vt testing was done
> that these problems were missed. Any one of these problems is enough cause
> to reverse the decision to make vt the default console driver for 11.0.
> This would give time for these problems to be address and correctly tested
> and when ready then be paced in some other 11.x release.


There is really no choice. vt(4) will work as a basic console on all
platforms. sc(4) works on old hardware, but not on an increasingly large
portion of "modern" hardware. Since being able to boot on most hardware is
critical as well as supporting non-CP437 languages. It' pretty much a
no-brainer. And, since switching back to SC(4) is trivial (add
"kern.vty=sc" to /boot/loader.conf), I believe any other option would be
totally unacceptable.

It is important that the release notes for 11 clarify these changes and
make it clear how to switch.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current

Re: console in 11.0-ALPHA4

[Ed Maste]

On 20 June 2016 at 23:22, John Baldwin  wrote:
>
> There are tradeoffs in both directions.  Neither console is a subset of the
> other.  However, sc(4) is not really extendable to support the things it is
> missing.  vt(4) is actively worked on, and patches for the features it lacks
> that you need are certainly welcomed.

You may also switch back to sc(4) by adding "kern.vty=sc" to /boot/loader.conf.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: console in 11.0-ALPHA4

[Ernie Luzar]

John Baldwin wrote:

On Monday, June 20, 2016 04:54:11 PM Ernie Luzar wrote:

Ed Maste wrote:

On 20 June 2016 at 14:29, Ernie Luzar  wrote:

I found the cause of this boot time message
"vicontrol: setting cursor type: Inappropriate ioctl for device"

In my rc.conf I had this statement
vidcontrol -c blink -h 250
From testing it seems that vt does not handle the "blink" option for causing
the cursor to blink. Is there a vt option to enable cursor  blinking

I've submitted two PRs for the issues you reported here:
Bug 210413 - vidcontrol -c  does not work with vt(4)
Bug 210415 - vidcontrol -h  does not work with vt(4) (edit)

There is currently no option to enable cursor blinking.


Further testing shows that:

1. The rc.conf option screen saver "saver= " and the "blanktime= " 
options work in vt for both text and graph modes.


2. The cursor copy/paste does not work in vt text mode. It only works in 
vt graph mode. vt needs to be fixed so copy/paste function also works in 
text mode.


3. Boot time splash screen does not work in vt at all no matter which 
mode is enabled. Using this in loader.conf

splash_bmp_load="YES"
bitmap_name="/boot/splash.bmp"
bitload_load="YES"

This works in 10.x. The splash screen function can not be allowed to be 
removed from the base system just because vt can not handle it. This 
also means any vt changes need to updated in the handbook section on 
splash screen.


In conclusion, vt is not ready to replace the sc console driver yet. vt 
needs to be fixed before becoming the default in 11.0. Using vt as the 
default console driver effects every user. It completely changes the 
FreeBSD experience. It's detrimental to the public relations and the 
professional image of FreeBSD to publish the 11.0-RELEASE using vt in 
its current condition. If time doesn't permit to get these vt things 
fixed before publishing 11.0 then vt should not become the default 
console driver.


OTOH, if you use EFI, then you can't use sc(4).  You get no working console
with EFI (which is becoming more popular) if you use sc(4).  You also do
not get non-ASCII characters with sc(4), so you don't have a UTF-8 capable
console if you use sc(4).  You also do not have a working console after
loading the KMS drivers (either by starting X or via explicit kldload) when
using sc(4).  This affects just about every modern Intel system using an
Intel GPU (so more widespread than EFI even).

There are trade offs in both directions.  Neither console is a subset of the
other.  However, sc(4) is not really expendable to support the things it is
missing.  vt(4) is actively worked on, and patches for the features it lacks
that you need are certainly welcomed.



This sounds like a integration design error. From your description of 
the hardware that vt is designed for and sc is designed for indicates 
the need for some code to be added to the boot process that inspects the 
hardware and decides whether vt or sc is to be launched. Or maybe 
bsdinstall should inspect the hardware and give the installer the option 
to select what console is best for his hardware. Just forcing this 
version of vt that lacks long time functions as the default console 
driver is not the professional way to handle such conflicts.


I am at a lost to understand how any development administrator would 
approve making vt the default console driver in light of the standard 
functions missing from it. And furthermore what kind of vt testing was 
done that these problems were missed. Any one of these problems is 
enough cause to reverse the decision to make vt the default console 
driver for 11.0. This would give time for these problems to be address 
and correctly tested and when ready then be paced in some other 11.x 
release.


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: console in 11.0-ALPHA4

[John Baldwin]

On Monday, June 20, 2016 04:54:11 PM Ernie Luzar wrote:
> Ed Maste wrote:
> > On 20 June 2016 at 14:29, Ernie Luzar  wrote:
> >> I found the cause of this boot time message
> >> "vicontrol: setting cursor type: Inappropriate ioctl for device"
> >>
> >> In my rc.conf I had this statement
> >> vidcontrol -c blink -h 250
> >> From testing it seems that vt does not handle the "blink" option for 
> >> causing
> >> the cursor to blink. Is there a vt option to enable cursor  blinking
> > 
> > I've submitted two PRs for the issues you reported here:
> > Bug 210413 - vidcontrol -c  does not work with 
> > vt(4)
> > Bug 210415 - vidcontrol -h  does not work with vt(4) (edit)
> > 
> > There is currently no option to enable cursor blinking.
> 
> 
> Further testing shows that:
> 
> 1. The rc.conf option screen saver "saver= " and the "blanktime= " 
> options work in vt for both text and graph modes.
> 
> 2. The cursor copy/paste does not work in vt text mode. It only works in 
> vt graph mode. vt needs to be fixed so copy/paste function also works in 
> text mode.
> 
> 3. Boot time splash screen does not work in vt at all no matter which 
> mode is enabled. Using this in loader.conf
> splash_bmp_load="YES"
> bitmap_name="/boot/splash.bmp"
> bitload_load="YES"
> 
> This works in 10.x. The splash screen function can not be allowed to be 
> removed from the base system just because vt can not handle it. This 
> also means any vt changes need to updated in the handbook section on 
> splash screen.
> 
> In conclusion, vt is not ready to replace the sc console driver yet. vt 
> needs to be fixed before becoming the default in 11.0. Using vt as the 
> default console driver effects every user. It completely changes the 
> FreeBSD experience. It's detrimental to the public relations and the 
> professional image of FreeBSD to publish the 11.0-RELEASE using vt in 
> its current condition. If time doesn't permit to get these vt things 
> fixed before publishing 11.0 then vt should not become the default 
> console driver.

OTOH, if you use EFI, then you can't use sc(4).  You get no working console
with EFI (which is becoming more popular) if you use sc(4).  You also do
not get non-ASCII characters with sc(4), so you don't have a UTF-8 capable
console if you use sc(4).  You also do not have a working console after
loading the KMS drivers (either by starting X or via explicit kldload) when
using sc(4).  This affects just about every modern Intel system using an
Intel GPU (so more widespread than EFI even).

There are tradeoffs in both directions.  Neither console is a subset of the
other.  However, sc(4) is not really extendable to support the things it is
missing.  vt(4) is actively worked on, and patches for the features it lacks
that you need are certainly welcomed.

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: console in 11.0-ALPHA4

[Ernie Luzar]

Ed Maste wrote:

On 20 June 2016 at 14:29, Ernie Luzar  wrote:

I found the cause of this boot time message
"vicontrol: setting cursor type: Inappropriate ioctl for device"

In my rc.conf I had this statement
vidcontrol -c blink -h 250
From testing it seems that vt does not handle the "blink" option for causing
the cursor to blink. Is there a vt option to enable cursor  blinking


I've submitted two PRs for the issues you reported here:
Bug 210413 - vidcontrol -c  does not work with vt(4)
Bug 210415 - vidcontrol -h  does not work with vt(4) (edit)

There is currently no option to enable cursor blinking.



Further testing shows that:

1. The rc.conf option screen saver "saver= " and the "blanktime= " 
options work in vt for both text and graph modes.


2. The cursor copy/paste does not work in vt text mode. It only works in 
vt graph mode. vt needs to be fixed so copy/paste function also works in 
text mode.


3. Boot time splash screen does not work in vt at all no matter which 
mode is enabled. Using this in loader.conf

splash_bmp_load="YES"
bitmap_name="/boot/splash.bmp"
bitload_load="YES"

This works in 10.x. The splash screen function can not be allowed to be 
removed from the base system just because vt can not handle it. This 
also means any vt changes need to updated in the handbook section on 
splash screen.


In conclusion, vt is not ready to replace the sc console driver yet. vt 
needs to be fixed before becoming the default in 11.0. Using vt as the 
default console driver effects every user. It completely changes the 
FreeBSD experience. It's detrimental to the public relations and the 
professional image of FreeBSD to publish the 11.0-RELEASE using vt in 
its current condition. If time doesn't permit to get these vt things 
fixed before publishing 11.0 then vt should not become the default 
console driver.






___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: console in 11.0-ALPHA4

[Ed Maste]

On 20 June 2016 at 14:29, Ernie Luzar  wrote:
>
> I found the cause of this boot time message
> "vicontrol: setting cursor type: Inappropriate ioctl for device"
>
> In my rc.conf I had this statement
> vidcontrol -c blink -h 250
> From testing it seems that vt does not handle the "blink" option for causing
> the cursor to blink. Is there a vt option to enable cursor  blinking

I've submitted two PRs for the issues you reported here:
Bug 210413 - vidcontrol -c  does not work with vt(4)
Bug 210415 - vidcontrol -h  does not work with vt(4) (edit)

There is currently no option to enable cursor blinking.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: console in 11.0-ALPHA4

[Ed Maste]

On 20 June 2016 at 12:45, Trond Endrestøl
 wrote:
>
> If you want textmode like in the old days, add this line to
> /boot/loader.conf:
>
> hw.vga.textmode="1"

One note, in textmode vt(4) is limited to cp437. The console still
uses Unicode internally but has a fixed lookup table to map to the
cp437 character set.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: console in 11.0-ALPHA4

[Ernie Luzar]

Trond Endrestøl wrote:

On Mon, 20 Jun 2016 11:36-0400, Ernie Luzar wrote:


I have installed 11.0-ALPHA4-i386-20160617-r301975.

The console looks very different from all previous releases.
I find it to be harder to read. This manifests it self with the boot log
messages and the normal behavior of the virtual consoles.

But the real problem is in the notable hesitation when switching between
virtual consoles.

From the boot log (ie: dmesg) I see this
VT(vga): resolution 640x480

This must be what is making the console display so different from
previous releases. Can VT be configured to default to present the same
console behavior as previous releases before this version of 11.0 gets
published as RELEASE?


If you want textmode like in the old days, add this line to 
/boot/loader.conf:


hw.vga.textmode="1"

You can also interrupt the final boot loader, and type:

set hw.vga.textmode="1"

Then type:

menu

or:

boot


About the "hesitation when switching between virtual consoles" I am
thinking that this reduced performance may be caused by WITNESS being
enabled in the ALPHA series of releases. Can anyone verify that this
hesitation will not exist in the published RELEASE?


The "hesitation" is sometimes hardware dependent. A GPU with a KMS 
driver makes it better. It's even worse in some virtualization 
environments, e.g. Microsoft Hyper-V.



In the boot log I get this message 16 times.
"vicontrol: setting cursor type: Inappropriate ioctl for device"
They don't seem to cause any problems that I have stumbled across.
Is anyone else getting these "NOTICE" type messages?


If you decide to continue with the vt console, you should consider the 
following:


With the new VT console in graphics mode, you don't need to load any 
fonts. Disable or remove any font lines from /etc/rc.conf.


I haven't tried the vt console in text mode lately, so maybe you need 
the fonts in that case.


Look for the appropriate keymap file in /usr/share/vt/keymaps/ and 
update the keymap line in /etc/rc.conf.


Here's the Norwegian keyboard layout as an example:

keymap="norwegian.iso" # Old Norwegian keymap for the sc console

keymap="no"# New Norwegian keymap for the vt console



On my 10.3-p4 system I added these 2 lines to loader.conf
kern.vty=vt
hw.vga.textmode=1

This change caused my 10.3 system to use "vt" and returned the console 
behavior look and feel to be just like the (sc(4) console. The 
"hesitation when switching between virtual consoles" also no longer 
happens.


I think its a mistake to default the vt console driver to graph mode in 
11.0. It should default to hw.vga.textmode=1 mode to be consistent with 
previous RELEASE versions of FreeBSD.


I found the cause of this boot time message
"vicontrol: setting cursor type: Inappropriate ioctl for device"

In my rc.conf I had this statement
vidcontrol -c blink -h 250
From testing it seems that vt does not handle the "blink" option for 
causing the cursor to blink. Is there a vt option to enable cursor  blinking



And while we are on fallout from vt becoming the default console driver 
in 11.0, what about the loader.conf options for "splash" screens and the 
rc.conf option screen saver "saver= " and the "blanktime= " option. 
Have these been reviewed?


Now here is the real show stopper. My rc.conf has
moused_flags="-m 2=3" to enable mouse copy and past.
This function on longer works under vt mode.










___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: console in 11.0-ALPHA4

[Trond Endrestøl]

On Mon, 20 Jun 2016 11:36-0400, Ernie Luzar wrote:

> I have installed 11.0-ALPHA4-i386-20160617-r301975.
> 
> The console looks very different from all previous releases.
> I find it to be harder to read. This manifests it self with the boot log
> messages and the normal behavior of the virtual consoles.
> 
> But the real problem is in the notable hesitation when switching between
> virtual consoles.
> 
> From the boot log (ie: dmesg) I see this
> VT(vga): resolution 640x480
> 
> This must be what is making the console display so different from
> previous releases. Can VT be configured to default to present the same
> console behavior as previous releases before this version of 11.0 gets
> published as RELEASE?

If you want textmode like in the old days, add this line to 
/boot/loader.conf:

hw.vga.textmode="1"

You can also interrupt the final boot loader, and type:

set hw.vga.textmode="1"

Then type:

menu

or:

boot

> About the "hesitation when switching between virtual consoles" I am
> thinking that this reduced performance may be caused by WITNESS being
> enabled in the ALPHA series of releases. Can anyone verify that this
> hesitation will not exist in the published RELEASE?

The "hesitation" is sometimes hardware dependent. A GPU with a KMS 
driver makes it better. It's even worse in some virtualization 
environments, e.g. Microsoft Hyper-V.

> In the boot log I get this message 16 times.
> "vicontrol: setting cursor type: Inappropriate ioctl for device"
> They don't seem to cause any problems that I have stumbled across.
> Is anyone else getting these "NOTICE" type messages?

If you decide to continue with the vt console, you should consider the 
following:

With the new VT console in graphics mode, you don't need to load any 
fonts. Disable or remove any font lines from /etc/rc.conf.

I haven't tried the vt console in text mode lately, so maybe you need 
the fonts in that case.

Look for the appropriate keymap file in /usr/share/vt/keymaps/ and 
update the keymap line in /etc/rc.conf.

Here's the Norwegian keyboard layout as an example:

keymap="norwegian.iso" # Old Norwegian keymap for the sc console

keymap="no"# New Norwegian keymap for the vt console

-- 
+---++
| Vennlig hilsen,   | Best regards,  |
| Trond Endrestøl,  | Trond Endrestøl,   |
| IT-ansvarlig, | System administrator,  |
| Fagskolen Innlandet,  | Gjøvik Technical College, Norway,  |
| tlf. mob.   952 62 567,   | Cellular...: +47 952 62 567,   |
| sentralbord 61 14 54 00.  | Switchboard: +47 61 14 54 00.  |
+---++
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: console in 11.0-ALPHA4

[John Baldwin]

On Monday, June 20, 2016 11:36:09 AM Ernie Luzar wrote:
> I have installed 11.0-ALPHA4-i386-20160617-r301975.
> 
> The console looks very different from all previous releases.
> I find it to be harder to read. This manifests it self with the boot log
> messages and the normal behavior of the virtual consoles.
> 
> But the real problem is in the notable hesitation when switching between
> virtual consoles.
> 
>  From the boot log (ie: dmesg) I see this
> VT(vga): resolution 640x480
> 
> This must be what is making the console display so different from
> previous releases. Can VT be configured to default to present the same
> console behavior as previous releases before this version of 11.0 gets
> published as RELEASE?

The difference is that vt(4) (the default console driver) only does software
rendering of fonts.  The older console driver syscons (sc(4)), used VGA text
mode which uses a font in your adapter's BIOS ROM.  The two fonts aren't
quite the same.  There is a 'vgarom' font you can try to use that should more
closely match the previous console.

> About the "hesitation when switching between virtual consoles" I am
> thinking that this reduced performance may be caused by WITNESS being
> enabled in the ALPHA series of releases. Can anyone verify that this
> hesitation will not exist in the published RELEASE?

I suspect this is just due to vt(4) rather than WITNESS.

> In the boot log I get this message 16 times.
> "vicontrol: setting cursor type: Inappropriate ioctl for device"
> They don't seem to cause any problems that I have stumbled across.
> Is anyone else getting these "NOTICE" type messages?

vt(4) doesn't support several features that sc(4) supports.  However,
sc(4) doesn't support framebuffer systems very well, and does not support
UTF-8, etc.  Note that for comparisons you can enable vt(4) on stable/10
by setting 'kern.vty=vt' in loader.conf or at the loader prompt.

-- 
John Baldwin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"