Re: vt(4) chops off the leftmost three columns

2017-01-24 Thread Adrian Chadd
hi!

Well, give it a go. I can only be supportive. :)


-a


On 24 January 2017 at 10:31, Anindya Mukherjee <anindy...@hotmail.com> wrote:
> Hi again,
>
> I have been switching back and forth between exploring the code and reading 
> J. Kong's Device Drivers book. As you explained, the first thing to tackle is 
> the coupling between vesa and sc. Right now I can't even load vesa unless the 
> kern.vty=sc, and then I cannot unload it.
>
> vesa depends on vesa.c and pulls in scvesactl.c for two functions: 
> vesa_load_ioctl() and vesa_unload_ioctl(). Although these are used only in 
> vesa.c, they depend on several structures (for example the virtual screen 
> structure scr_stat, and others) defined in syscons.h, which makes these two 
> systems coupled.
>
> I was wondering what would be a good way to decouple these dependencies. I 
> want to do the right thing even if it takes longer. Really appreciate you 
> taking the time to respond, thanks!
>
> Anindya
> 
> From: Adrian Chadd [adrian.ch...@gmail.com]
> Sent: January 20, 2017 3:11 PM
> To: Anindya Mukherjee
> Cc: freebsd-current@freebsd.org
> Subject: Re: vt(4) chops off the leftmost three columns
>
> hiya,
>
> Mechanically it doesn't look /that/ hard:
>
> * vesa.ko pulls in the vesa.c bits and the syscons vesa control bits.
> Ideally we'd have them as two separate modules, so you could load
> "vesa" without needing the syscons bits.
> * Maybe then write a vt 'fb' interface to talk to the old-school
> framebuffer interface
> * Then (if we're lucky) we can have vt use the same VGA, VESA, (mach,
> creator, etc!) through the fb interface, rather than reimplementing
> its own.
>
> I looked at it and it doesn't look /that/ hard. If you only cared
> about vesa, then you could do something like what 'creator' and
> 'creator_vt' did in sys/dev/fb/ . It's just sad that the vt interface
> to the screen buffer isn't as complete as the older school framebuffer
> interface is.
>
>
> -adrian
>
>
> On 19 January 2017 at 12:35, Anindya Mukherjee <anindy...@hotmail.com> wrote:
>> Hi Adrian,
>>
>> I was looking at the source for the vt driver. Wondering how much work it is 
>> to add VESA support to the VGA backend? As you say ATM it's hardcoded to use 
>> 640x480. Pardon my ignorance, but can we reuse any VESA code from syscons?
>>
>> Also, how dependent is splash/screensaver support on the VESA implementation?
>>
>> Thanks,
>> Anindya
___
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: vt(4) chops off the leftmost three columns

2017-01-24 Thread Anindya Mukherjee
Hi again,

I have been switching back and forth between exploring the code and reading J. 
Kong's Device Drivers book. As you explained, the first thing to tackle is the 
coupling between vesa and sc. Right now I can't even load vesa unless the 
kern.vty=sc, and then I cannot unload it.

vesa depends on vesa.c and pulls in scvesactl.c for two functions: 
vesa_load_ioctl() and vesa_unload_ioctl(). Although these are used only in 
vesa.c, they depend on several structures (for example the virtual screen 
structure scr_stat, and others) defined in syscons.h, which makes these two 
systems coupled.

I was wondering what would be a good way to decouple these dependencies. I want 
to do the right thing even if it takes longer. Really appreciate you taking the 
time to respond, thanks!

Anindya

From: Adrian Chadd [adrian.ch...@gmail.com]
Sent: January 20, 2017 3:11 PM
To: Anindya Mukherjee
Cc: freebsd-current@freebsd.org
Subject: Re: vt(4) chops off the leftmost three columns

hiya,

Mechanically it doesn't look /that/ hard:

* vesa.ko pulls in the vesa.c bits and the syscons vesa control bits.
Ideally we'd have them as two separate modules, so you could load
"vesa" without needing the syscons bits.
* Maybe then write a vt 'fb' interface to talk to the old-school
framebuffer interface
* Then (if we're lucky) we can have vt use the same VGA, VESA, (mach,
creator, etc!) through the fb interface, rather than reimplementing
its own.

I looked at it and it doesn't look /that/ hard. If you only cared
about vesa, then you could do something like what 'creator' and
'creator_vt' did in sys/dev/fb/ . It's just sad that the vt interface
to the screen buffer isn't as complete as the older school framebuffer
interface is.


-adrian


On 19 January 2017 at 12:35, Anindya Mukherjee <anindy...@hotmail.com> wrote:
> Hi Adrian,
>
> I was looking at the source for the vt driver. Wondering how much work it is 
> to add VESA support to the VGA backend? As you say ATM it's hardcoded to use 
> 640x480. Pardon my ignorance, but can we reuse any VESA code from syscons?
>
> Also, how dependent is splash/screensaver support on the VESA implementation?
>
> Thanks,
> Anindya
___
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: vt(4) chops off the leftmost three columns

2017-01-21 Thread Anindya Mukherjee
Thanks! I needed a breakdown like this. I'll need to study the code a bit more.

Anindya

From: Adrian Chadd [adrian.ch...@gmail.com]
Sent: January 20, 2017 3:11 PM
To: Anindya Mukherjee
Cc: freebsd-current@freebsd.org
Subject: Re: vt(4) chops off the leftmost three columns

hiya,

Mechanically it doesn't look /that/ hard:

* vesa.ko pulls in the vesa.c bits and the syscons vesa control bits.
Ideally we'd have them as two separate modules, so you could load
"vesa" without needing the syscons bits.
* Maybe then write a vt 'fb' interface to talk to the old-school
framebuffer interface
* Then (if we're lucky) we can have vt use the same VGA, VESA, (mach,
creator, etc!) through the fb interface, rather than reimplementing
its own.

I looked at it and it doesn't look /that/ hard. If you only cared
about vesa, then you could do something like what 'creator' and
'creator_vt' did in sys/dev/fb/ . It's just sad that the vt interface
to the screen buffer isn't as complete as the older school framebuffer
interface is.


-adrian


On 19 January 2017 at 12:35, Anindya Mukherjee <anindy...@hotmail.com> wrote:
> Hi Adrian,
>
> I was looking at the source for the vt driver. Wondering how much work it is 
> to add VESA support to the VGA backend? As you say ATM it's hardcoded to use 
> 640x480. Pardon my ignorance, but can we reuse any VESA code from syscons?
>
> Also, how dependent is splash/screensaver support on the VESA implementation?
>
> Thanks,
> Anindya
___
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: vt(4) chops off the leftmost three columns

2017-01-20 Thread Adrian Chadd
hiya,

Mechanically it doesn't look /that/ hard:

* vesa.ko pulls in the vesa.c bits and the syscons vesa control bits.
Ideally we'd have them as two separate modules, so you could load
"vesa" without needing the syscons bits.
* Maybe then write a vt 'fb' interface to talk to the old-school
framebuffer interface
* Then (if we're lucky) we can have vt use the same VGA, VESA, (mach,
creator, etc!) through the fb interface, rather than reimplementing
its own.

I looked at it and it doesn't look /that/ hard. If you only cared
about vesa, then you could do something like what 'creator' and
'creator_vt' did in sys/dev/fb/ . It's just sad that the vt interface
to the screen buffer isn't as complete as the older school framebuffer
interface is.


-adrian


On 19 January 2017 at 12:35, Anindya Mukherjee  wrote:
> Hi Adrian,
>
> I was looking at the source for the vt driver. Wondering how much work it is 
> to add VESA support to the VGA backend? As you say ATM it's hardcoded to use 
> 640x480. Pardon my ignorance, but can we reuse any VESA code from syscons?
>
> Also, how dependent is splash/screensaver support on the VESA implementation?
>
> Thanks,
> Anindya
___
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: vt(4) chops off the leftmost three columns

2017-01-19 Thread Anindya Mukherjee
Hi Adrian,

I was looking at the source for the vt driver. Wondering how much work it is to 
add VESA support to the VGA backend? As you say ATM it's hardcoded to use 
640x480. Pardon my ignorance, but can we reuse any VESA code from syscons?

Also, how dependent is splash/screensaver support on the VESA implementation?

Thanks,
Anindya
___
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: vt(4) chops off the leftmost three columns

2017-01-14 Thread Adrian Chadd
heh.

As always, patches gratefully accepted. :)



-adrian


On 14 January 2017 at 21:07, Ernie Luzar  wrote:
>
> You can add these things to the vt to-do list
>
> Change the default font to look like sc.
> Add copy/paste function like sc has.
> Add splash screen support like sc has.
>
>
>
> Adrian Chadd wrote:
>>
>> hi,
>>
>> no, the vt_vga backend doesn't yet do VESA.
>>
>> I keep meaning to sit down and fix this, but life and wifi gets in the
>> way.
>>
>>
>> -adrian
>>
>>
>> On 14 January 2017 at 16:27, Kevin Oberman  wrote:
>>>
>>> On Sat, Jan 14, 2017 at 2:11 PM, Adrian Chadd 
>>> wrote:

 It depends(tm). I think the VT code just does "640x480x4bpp" and lets
 the BIOS sort it out. A lot of things don't cope well with 640x480
 these days - they try autodetecting picture edges, but a black border
 makes that very difficult.


 -adrian
>>>
>>>
>>> Can you use vidcontrol(1) to change to something better? 1600x900, maybe?
>>> (Note, I have not tried this and I know that vt does not support a lot of
>>> vidcontrol functionality, but starting X sets the display to 200x56
>>> characters on my laptop.)
>>> --
>>> Kevin Oberman, Part time kid herder and retired Network Engineer
>>> E-mail: rkober...@gmail.com
>>> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
>>>
>>>
 On 14 January 2017 at 08:57, Matthias Andree 
 wrote:
>
> Am 14.01.2017 um 00:11 schrieb Alan Somers:
>>
>> I take it back.  The first three columns _are_ rendered, but they
>> don't show up on some monitiors.  It's as if those monitors require a
>> minimum amount of overscan on the left side of the screen, and vt(4)
>> doesn't provide enough.  Can that be tuned?
>
> Once upon a time, I've seen similar things on Linux, but with fewer
> pixels offset, when switching framebuffer drivers - back then, the
> scanning-VGA-timing was an issue. Is there any way to tweak the row and
> column timings, with blank periods, viewport offsets and thereabouts?
>
>
>
___
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: vt(4) chops off the leftmost three columns

2017-01-14 Thread Ernie Luzar


You can add these things to the vt to-do list

Change the default font to look like sc.
Add copy/paste function like sc has.
Add splash screen support like sc has.


Adrian Chadd wrote:

hi,

no, the vt_vga backend doesn't yet do VESA.

I keep meaning to sit down and fix this, but life and wifi gets in the way.


-adrian


On 14 January 2017 at 16:27, Kevin Oberman  wrote:

On Sat, Jan 14, 2017 at 2:11 PM, Adrian Chadd 
wrote:

It depends(tm). I think the VT code just does "640x480x4bpp" and lets
the BIOS sort it out. A lot of things don't cope well with 640x480
these days - they try autodetecting picture edges, but a black border
makes that very difficult.


-adrian


Can you use vidcontrol(1) to change to something better? 1600x900, maybe?
(Note, I have not tried this and I know that vt does not support a lot of
vidcontrol functionality, but starting X sets the display to 200x56
characters on my laptop.)
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683



On 14 January 2017 at 08:57, Matthias Andree 
wrote:

Am 14.01.2017 um 00:11 schrieb Alan Somers:

I take it back.  The first three columns _are_ rendered, but they
don't show up on some monitiors.  It's as if those monitors require a
minimum amount of overscan on the left side of the screen, and vt(4)
doesn't provide enough.  Can that be tuned?

Once upon a time, I've seen similar things on Linux, but with fewer
pixels offset, when switching framebuffer drivers - back then, the
scanning-VGA-timing was an issue. Is there any way to tweak the row and
column timings, with blank periods, viewport offsets and thereabouts?



___
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: vt(4) chops off the leftmost three columns

2017-01-14 Thread Adrian Chadd
hi,

no, the vt_vga backend doesn't yet do VESA.

I keep meaning to sit down and fix this, but life and wifi gets in the way.


-adrian


On 14 January 2017 at 16:27, Kevin Oberman  wrote:
> On Sat, Jan 14, 2017 at 2:11 PM, Adrian Chadd 
> wrote:
>>
>> It depends(tm). I think the VT code just does "640x480x4bpp" and lets
>> the BIOS sort it out. A lot of things don't cope well with 640x480
>> these days - they try autodetecting picture edges, but a black border
>> makes that very difficult.
>>
>>
>> -adrian
>
>
> Can you use vidcontrol(1) to change to something better? 1600x900, maybe?
> (Note, I have not tried this and I know that vt does not support a lot of
> vidcontrol functionality, but starting X sets the display to 200x56
> characters on my laptop.)
> --
> Kevin Oberman, Part time kid herder and retired Network Engineer
> E-mail: rkober...@gmail.com
> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
>
>
>>
>> On 14 January 2017 at 08:57, Matthias Andree 
>> wrote:
>> > Am 14.01.2017 um 00:11 schrieb Alan Somers:
>> >> I take it back.  The first three columns _are_ rendered, but they
>> >> don't show up on some monitiors.  It's as if those monitors require a
>> >> minimum amount of overscan on the left side of the screen, and vt(4)
>> >> doesn't provide enough.  Can that be tuned?
>> >
>> > Once upon a time, I've seen similar things on Linux, but with fewer
>> > pixels offset, when switching framebuffer drivers - back then, the
>> > scanning-VGA-timing was an issue. Is there any way to tweak the row and
>> > column timings, with blank periods, viewport offsets and thereabouts?
>> > ___
>> > 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"
>
>
___
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: vt(4) chops off the leftmost three columns

2017-01-14 Thread Kevin Oberman
On Sat, Jan 14, 2017 at 2:11 PM, Adrian Chadd 
wrote:

> It depends(tm). I think the VT code just does "640x480x4bpp" and lets
> the BIOS sort it out. A lot of things don't cope well with 640x480
> these days - they try autodetecting picture edges, but a black border
> makes that very difficult.
>
>
> -adrian
>

Can you use vidcontrol(1) to change to something better? 1600x900, maybe?
(Note, I have not tried this and I know that vt does not support a lot of
vidcontrol functionality, but starting X sets the display to 200x56
characters on my laptop.)
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683



> On 14 January 2017 at 08:57, Matthias Andree 
> wrote:
> > Am 14.01.2017 um 00:11 schrieb Alan Somers:
> >> I take it back.  The first three columns _are_ rendered, but they
> >> don't show up on some monitiors.  It's as if those monitors require a
> >> minimum amount of overscan on the left side of the screen, and vt(4)
> >> doesn't provide enough.  Can that be tuned?
> >
> > Once upon a time, I've seen similar things on Linux, but with fewer
> > pixels offset, when switching framebuffer drivers - back then, the
> > scanning-VGA-timing was an issue. Is there any way to tweak the row and
> > column timings, with blank periods, viewport offsets and thereabouts?
> > ___
> > freebsd-current@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-current
> > To unsubscribe, send any mail to "freebsd-current-unsubscribe@
> 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"
>
___
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: vt(4) chops off the leftmost three columns

2017-01-14 Thread Adrian Chadd
It depends(tm). I think the VT code just does "640x480x4bpp" and lets
the BIOS sort it out. A lot of things don't cope well with 640x480
these days - they try autodetecting picture edges, but a black border
makes that very difficult.


-adrian


On 14 January 2017 at 08:57, Matthias Andree  wrote:
> Am 14.01.2017 um 00:11 schrieb Alan Somers:
>> I take it back.  The first three columns _are_ rendered, but they
>> don't show up on some monitiors.  It's as if those monitors require a
>> minimum amount of overscan on the left side of the screen, and vt(4)
>> doesn't provide enough.  Can that be tuned?
>
> Once upon a time, I've seen similar things on Linux, but with fewer
> pixels offset, when switching framebuffer drivers - back then, the
> scanning-VGA-timing was an issue. Is there any way to tweak the row and
> column timings, with blank periods, viewport offsets and thereabouts?
> ___
> 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: vt(4) chops off the leftmost three columns

2017-01-14 Thread Alan Somers
On Sat, Jan 14, 2017 at 4:43 AM, David Chisnall  wrote:
> On 13 Jan 2017, at 01:00, Ernie Luzar  wrote:
>>
>> VT should have had better testing before becoming the default in 11.0.
>
> The choice was VT or no acceleration in X11, because all of the new DRI 
> drivers depend on KMS, which requires VT.  We only got VT in a useable state 
> (and therefore useable accelerated X11 for most of the 10.x series) because 
> the Foundation funded the work.  More contributions to VT are always welcome, 
> but the choice was not between VT or something better tested, it was between 
> VT and black screens.
>
> David

I should add, BTW, that on my Haswell desktop, the only place where I
care about graphics, vt(4) works great.  It works better than Linux
did on the same hardware.  It also uses a DVI monitor, so there are no
issues with the borders.

-Alan
___
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: vt(4) chops off the leftmost three columns

2017-01-14 Thread Matthias Andree
Am 14.01.2017 um 00:11 schrieb Alan Somers:
> I take it back.  The first three columns _are_ rendered, but they
> don't show up on some monitiors.  It's as if those monitors require a
> minimum amount of overscan on the left side of the screen, and vt(4)
> doesn't provide enough.  Can that be tuned?

Once upon a time, I've seen similar things on Linux, but with fewer
pixels offset, when switching framebuffer drivers - back then, the
scanning-VGA-timing was an issue. Is there any way to tweak the row and
column timings, with blank periods, viewport offsets and thereabouts?
___
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: vt(4) chops off the leftmost three columns

2017-01-14 Thread David Chisnall
On 13 Jan 2017, at 01:00, Ernie Luzar  wrote:
> 
> VT should have had better testing before becoming the default in 11.0.

The choice was VT or no acceleration in X11, because all of the new DRI drivers 
depend on KMS, which requires VT.  We only got VT in a useable state (and 
therefore useable accelerated X11 for most of the 10.x series) because the 
Foundation funded the work.  More contributions to VT are always welcome, but 
the choice was not between VT or something better tested, it was between VT and 
black screens.

David



smime.p7s
Description: S/MIME cryptographic signature


Re: vt(4) chops off the leftmost three columns

2017-01-13 Thread Alan Somers
On Thu, Jan 12, 2017 at 7:31 PM, Ngie Cooper (yaneurabeya)
<yaneurab...@gmail.com> wrote:
>
>> On Jan 12, 2017, at 18:13, Ed Maste <ema...@freebsd.org> wrote:
>>
>> On 12 January 2017 at 18:50, Alan Somers <asom...@freebsd.org> wrote:
>>> I've seen three separate machines where FreeBSD11's vt(4) driver chops
>>> off the leftmost three columns of the screen.  Rendering simply starts
>>> at the beginning of the fourth column.  In all cases, setting
>>> "kern.vty=sc" corrects the problem.
>>
>> Or try setting hw.vga.textmode=1
>>
>> Did you observe this with IPMI redirected video or an attached monitor
>> (or a combination)?
>
> I’ll have to double check, but I’m pretty sure I’ve seen this with my Haswell 
> box (Escher) over VGA using my projector.
> Thanks,
> -Ngie

I take it back.  The first three columns _are_ rendered, but they
don't show up on some monitiors.  It's as if those monitors require a
minimum amount of overscan on the left side of the screen, and vt(4)
doesn't provide enough.  Can that be tuned?
-Alan
___
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: vt(4) chops off the leftmost three columns

2017-01-12 Thread Ngie Cooper (yaneurabeya)

> On Jan 12, 2017, at 18:13, Ed Maste <ema...@freebsd.org> wrote:
> 
> On 12 January 2017 at 18:50, Alan Somers <asom...@freebsd.org> wrote:
>> I've seen three separate machines where FreeBSD11's vt(4) driver chops
>> off the leftmost three columns of the screen.  Rendering simply starts
>> at the beginning of the fourth column.  In all cases, setting
>> "kern.vty=sc" corrects the problem.
> 
> Or try setting hw.vga.textmode=1
> 
> Did you observe this with IPMI redirected video or an attached monitor
> (or a combination)?

I’ll have to double check, but I’m pretty sure I’ve seen this with my Haswell 
box (Escher) over VGA using my projector.
Thanks,
-Ngie



signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: vt(4) chops off the leftmost three columns

2017-01-12 Thread Ed Maste
On 12 January 2017 at 18:50, Alan Somers <asom...@freebsd.org> wrote:
> I've seen three separate machines where FreeBSD11's vt(4) driver chops
> off the leftmost three columns of the screen.  Rendering simply starts
> at the beginning of the fourth column.  In all cases, setting
> "kern.vty=sc" corrects the problem.

Or try setting hw.vga.textmode=1

Did you observe this with IPMI redirected video or an attached monitor
(or a combination)?
___
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: vt(4) chops off the leftmost three columns

2017-01-12 Thread Ernie Luzar

Alan Somers wrote:

I've seen three separate machines where FreeBSD11's vt(4) driver chops
off the leftmost three columns of the screen.  Rendering simply starts
at the beginning of the fourth column.  In all cases, setting
"kern.vty=sc" corrects the problem.  The three different systems are:

1) Haswell CPU with SuperMicro X10DRH-IT motherboard
2) Gainestown CPU with Dell S99 motherboard
3) Via Nano X2 CPU with VIA EPIA-M900 motherboard

I don't have time to hack on vt myself as long as sc works fine.  But
if there's any way that I can help a vt developer, I'd be happy to do
it.

-Alan


VT(4) already has open problems that no one is working on so may as well 
add this as another pr.


VT should have had better testing before becoming the default in 11.0.

___
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"


vt(4) chops off the leftmost three columns

2017-01-12 Thread Alan Somers
I've seen three separate machines where FreeBSD11's vt(4) driver chops
off the leftmost three columns of the screen.  Rendering simply starts
at the beginning of the fourth column.  In all cases, setting
"kern.vty=sc" corrects the problem.  The three different systems are:

1) Haswell CPU with SuperMicro X10DRH-IT motherboard
2) Gainestown CPU with Dell S99 motherboard
3) Via Nano X2 CPU with VIA EPIA-M900 motherboard

I don't have time to hack on vt myself as long as sc works fine.  But
if there's any way that I can help a vt developer, I'd be happy to do
it.

-Alan
___
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"