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

2017-01-24 Thread Adrian Chadd
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 >

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

2017-01-24 Thread Anindya Mukherjee
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

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

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

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

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

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

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: >> >>

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 >

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

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

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

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

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

2017-01-13 Thread Alan Somers
n 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 t

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

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

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 syste

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) H