[CALL FOR TESTERS] VESA High Resolution Console support from DragonFly

[Xin LI]

Dear -CURRENT users,

I would like to solicit a test of the following patchset which is based
on DragonFly's changes, against -CURRENT, to bring high resolution console
support to FreeBSD. The current patchset can be considered as "BETA" and
I would commit it if there is no complain about this patchset in the next
week.

The patchset can be found at:
http://people.freebsd.org/~delphij/vesa/patchset-highres.20050522

To use it, you will need latest -CURRENT code, and apply the patchset at
toplevel source tree, i.e. /usr/src for usual cases. Then you need to build
and reinstall your kernel, with 'options SC_PIXEL_MODE' compiled in, and
optionally options VESA if you don't want to manually load VESA support
module. A make buildworld/installworld is recommended, but I believe that
just rebuild/reinstall usr.sbin/vidcontrol is enough to get your hands on
the support for using something like 'vidcontrol MODE_239' or so, which will
switch the current console to that mode. Some mode may not work on certain
cards, though.

Please let me know if anything strange happens; While I have been running
with the patch for a while, I would still be happy if you will report that
it works :-)

Thanks in advance!

Cheers,
--
Xin LI <delphij frontfree net> http://www.delphij.net/
See complete headers for GPG key and other information.

[Alexandre "Sunny" Kovalenko]

Works very well here (Averatec 3150H notebook with S3 ProSavage video
chipset). Current sources are from May 14.

I was able to switch console into 1024x768x32 (mode 280).

Mouse cursor displays and moves around, but since I am not using mouse
on the console I could not report much on that.

Thank you very much,
--
Alexandre "Sunny" Kovalenko (Олександр Ковале
нко)

_______________________________________________
freebsd...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-curre...@freebsd.org
"

[Alexandre "Sunny" Kovalenko]

On Sun, 2005-05-22 at 19:26 +0800, Xin LI wrote:

I have observed some odd behavior when X display becomes garbled if USB
stack is loaded and USB keyboard is attached after user has logged into
X desktop (Gnome in my case). I am setting MODE_280 (1024x768x32) in
rc.conf using 'allscreens_flags'.

I have been playing with it a bit and found out that I can achieve the
same result by doing 'vidcontrol MODE_280 < /dev/ttyv8 > /dev/ttyv8'
after logging into Gnome. And ttyv8 is the terminal, occupied by X
display. Restarting X server cures the problem.

Neither original scenario, nor the second one are very likely, so I do
not know whether it is much of a problem.

I am running -CURRENT from May 14th, video chipset is S3 ProSavage.

Please, let me know if there is any additional information that I can
provide.

[Jeremie Le Hen]

Hi Xin,

Thanks for your work.

I have used the patch for five minutes now and it seems to work well.
I can switch to multiple resolutions (640x480, 800x600, 1024x768), switch
console. When I set a non-supported resolution, the screen stay blanked
a few seconds and then goes back to the last resolution telling this
operation is not supported by device. Perfect.

The mouse cursor is BEAUTIFUL !! It's far more better than the standard
one in classic console mode.

Note that I don't use either X or an USB mouse on this laptop. The video
card is an ATI Radeon X700.

One question however : is it supposed to consume more CPU than classical
non-VESA text mode ?

Thanks again for your work and Sacha Wildner's.

Best regards,
--
Jeremie Le Hen
< jeremie at le-hen dot org >< ttz at chchile dot org >

[Kevin Oberman]

> Date: Sun, 22 May 2005 19:26:12 +0800
> From: Xin LI <del...@frontfree.net>
> Sender: owner-free...@freebsd.org

I rebuilt my kernel and vidcontrol and tried it out.

First, the good news is that 'vidcontrol -i mode' showed all of the
graphics modes; about 60 of them!

Now, the bad news: Setting the mode does not work.
# vidcontrol MODE_387
vidcontrol: Setting video mode: Inappropriate ioctl for device
or
# vidcontrol MODE_281
vidcontrol: cannot activate raster mode: Inappropriate ioctl for device

I'm running on an IBM T30 with Radeon M7 video and current as of Friday.

Was there something other than te kernel and vidcontrol that I should
have rebuilt? I did not rebuild my modules.
--
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: obe...@es.net Phone: +1 510 486-8634

[Giorgos Keramidas]

On 2005-05-22 19:26, Xin LI <del...@frontfree.net> wrote:
> Dear -CURRENT users,
> I would like to solicit a test of the following patchset which is based
> on DragonFly's changes, against -CURRENT, to bring high resolution console
> support to FreeBSD. The current patchset can be considered as "BETA" and
> I would commit it if there is no complain about this patchset in the next
> week.
>
> The patchset can be found at:
> http://people.freebsd.org/~delphij/vesa/patchset-highres.20050522

First of all, a big *thanks* for your work :-)

I just rebuilt my kernel+world from today's sources, installed, then
patched and reinstalled kernel+vidcontrol. All seems to work fine, and
I can use a console of 1024x768, switch between consoles with different
modes, start X11 and then stop it again and have the console return to
its previous mode, etc.

Almost everything seems to work absolutely great. Except for one minor
detail:

When I double click on a word, to select this word in a console window,
the characters under the cursor and 1-2 characters after it get messed
up a bit (i.e. foreground and background colors getting a bit mixed up
where the cursor "covers" parts of the characters).

- Giorgos

[Xin LI]

Hi, Jeremie,

在 2005-05-23一的 02:38 +0200，Jeremie Le Hen写道：
[snip]

> One question however : is it supposed to consume more CPU than classical
> non-VESA text mode ?

I think so, it should consume more CPU than classical text mode console
since it draws characters, rather than giving the responsibility to the
video card. A possible optimization would be to map the video card
memory into the space.

Cheers,
--
Xin LI <delphij delphij net> http://www.delphij.net/

[Xin LI]

Hi, Alexandre,

On Sun, May 22, 2005 at 02:43:43PM -0400, Alexandre Sunny Kovalenko wrote:
> On Sun, 2005-05-22 at 19:26 +0800, Xin LI wrote:

[snip]

> I have observed some odd behavior when X display becomes garbled if USB
> stack is loaded and USB keyboard is attached after user has logged into
> X desktop (Gnome in my case). I am setting MODE_280 (1024x768x32) in
> rc.conf using 'allscreens_flags'.
>
> I have been playing with it a bit and found out that I can achieve the
> same result by doing 'vidcontrol MODE_280 < /dev/ttyv8 > /dev/ttyv8'
> after logging into Gnome. And ttyv8 is the terminal, occupied by X
> display. Restarting X server cures the problem.

Thanks for the feedback. I don't have an USB keyboard at hand but I will
try if I would be able to track it down.

Cheers,
--

[Jeremie Le Hen]

Xin,

> I have used the patch for five minutes now and it seems to work well.
> I can switch to multiple resolutions (640x480, 800x600, 1024x768), switch
> console. When I set a non-supported resolution, the screen stay blanked
> a few seconds and then goes back to the last resolution telling this
> operation is not supported by device. Perfect.

Nearly perfect :-). I use the fade saver and when I woke up this morning,
going back from the screen saver turned the VESA console text into blue.
Not the whole text, just the non-brilliant one. This is not the case on
non-VESA consoles.

Switching to another console suffices to get back the orignal text color.
I didn't tested whether the blue turns into another color if I change the
default text color, but displaying various colors with vim (blue, red,
yellow), it appears that all colors are, at least, darkened. Note that
as far as I tested, this is not specific to any screensaver, it seems to
be ensued by a generic piece of code. I tried changing the resolution
and I managed to get another color : instead of blue, I got red :-).

Regards,

[Jeremie Le Hen]

> Almost everything seems to work absolutely great. Except for one minor
> detail:
>
> When I double click on a word, to select this word in a console window,
> the characters under the cursor and 1-2 characters after it get messed
> up a bit (i.e. foreground and background colors getting a bit mixed up
> where the cursor "covers" parts of the characters).

Confirmed.

Another question : many notebook screens now support what I would call
bastard resolution (something like 1280x800 IIRC). Is there any way to
get these kind of modes ? Currently it seems not, but I wonder if it
would be easily possible.

Thanks.

--
Jeremie Le Hen
< jeremie at le-hen dot org >< ttz at chchile dot org >

[Stefan Ehmann]

On Mon, 2005-05-23 at 10:08 +0200, Jeremie Le Hen wrote:
> > Almost everything seems to work absolutely great. Except for one minor
> > detail:
> >
> > When I double click on a word, to select this word in a console window,
> > the characters under the cursor and 1-2 characters after it get messed
> > up a bit (i.e. foreground and background colors getting a bit mixed up
> > where the cursor "covers" parts of the characters).
>
> Confirmed.
>
> Another question : many notebook screens now support what I would call
> bastard resolution (something like 1280x800 IIRC). Is there any way to
> get these kind of modes ? Currently it seems not, but I wonder if it
> would be easily possible.

I got following modes listed that just work fine:

380 (0x17c) 0x0000000f G 1280x800x8 1 8x16 0xa0000 64k 64k
0xe8000000 32576k
381 (0x17d) 0x0000000f G 1280x800x16 1 8x16 0xa0000 64k 64k
0xe8000000 32576k
382 (0x17e) 0x0000000f G 1280x800x32 1 8x16 0xa0000 64k 64k
0xe8000000 32576k

--
Stefan Ehmann

[Eric Anderson]

Xin LI wrote:
> Dear -CURRENT users,
>
> I would like to solicit a test of the following patchset which is based
> on DragonFly's changes, against -CURRENT, to bring high resolution console
> support to FreeBSD. The current patchset can be considered as "BETA" and
> I would commit it if there is no complain about this patchset in the next
> week.
>
> The patchset can be found at:
> http://people.freebsd.org/~delphij/vesa/patchset-highres.20050522
>
> To use it, you will need latest -CURRENT code, and apply the patchset at
> toplevel source tree, i.e. /usr/src for usual cases. Then you need to build
> and reinstall your kernel, with 'options SC_PIXEL_MODE' compiled in, and
> optionally options VESA if you don't want to manually load VESA support
> module. A make buildworld/installworld is recommended, but I believe that
> just rebuild/reinstall usr.sbin/vidcontrol is enough to get your hands on
> the support for using something like 'vidcontrol MODE_239' or so, which will
> switch the current console to that mode. Some mode may not work on certain
> cards, though.
>
> Please let me know if anything strange happens; While I have been running
> with the patch for a while, I would still be happy if you will report that
> it works :-)

This seems to work nicely for me (Dell Latitude D610, Radeon X300,
1400x1050x16,24,or 32). Only thing I saw was my machine locked up once
after leaving X, but I could not reproduce it.

Eric

--
------------------------------------------------------------------------
Eric Anderson Sr. Systems Administrator Centaur Technology
A lost ounce of gold may be found, a lost moment of time never.
------------------------------------------------------------------------

[Greg Hennessy]

On Mon, 23 May 2005 01:40:07 UTC, "Kevin Oberman" <obe...@es.net> wrote:

>Now, the bad news: Setting the mode does not work.
># vidcontrol MODE_387
>vidcontrol: Setting video mode: Inappropriate ioctl for device
>or
># vidcontrol MODE_281
>vidcontrol: cannot activate raster mode: Inappropriate ioctl for device
>

Seeing similar here with a Vaio and its onboard i810 graphics. Obviously
not all VBEs are created equal.

Works just fine on my other system here with a matrox millenium.

greg

--
Contains minor peril

[Eric Kjeldergaard]

2005/5/23, Xin LI <del...@frontfree.net>:

> Hi, Jeremie,
>
> 在 2005-05-23一的 02:38 +0200，Jeremie Le Hen写道：
> [snip]
> > One question however : is it supposed to consume more CPU than classical
> > non-VESA text mode ?
>
> I think so, it should consume more CPU than classical text mode console
> since it draws characters, rather than giving the responsibility to the
> video card. A possible optimization would be to map the video card
> memory into the space.

Tested on my Thinkpad R40 : Radeon 7500. Is it supposed to consume a
LOT of cpu? Perhaps there's something funny with -O2 or similar
because some things are VERY slow. I have not, however, noticed any
major bugs, but screen redraws will take ~1 second if the screen is
not cleared and thus causes powerd to kick my processor up to full
speed often. Also, the screensaver (logo_saver) seems to take a while
to display. The screen goes black for 10 - 15 seconds before the
screen saver displays. Through all this, though, it's still so worth
it.

--
If I write a signature, my emails will appear more personalised.

[Eric Kjeldergaard]

2005/5/25, Xin LI <del...@delphij.net>:
> Hi, Eric,
>
> 在 2005-05-25三的 13:28 +0900，Eric Kjeldergaard写道：

> > 2005/5/23, Xin LI <del...@frontfree.net>:
> > > Hi, Jeremie,
> > >
> > > 在 2005-05-23一的 02:38 +0200，Jeremie Le Hen写道：
> > > [snip]
> > > > One question however : is it supposed to consume more CPU than classical
> > > > non-VESA text mode ?
> > >
> > > I think so, it should consume more CPU than classical text mode console
> > > since it draws characters, rather than giving the responsibility to the
> > > video card. A possible optimization would be to map the video card
> > > memory into the space.
> >
> > Tested on my Thinkpad R40 : Radeon 7500. Is it supposed to consume a
> > LOT of cpu? Perhaps there's something funny with -O2 or similar
> > because some things are VERY slow. I have not, however, noticed any
> > major bugs, but screen redraws will take ~1 second if the screen is
> > not cleared and thus causes powerd to kick my processor up to full
> > speed often. Also, the screensaver (logo_saver) seems to take a while
> > to display. The screen goes black for 10 - 15 seconds before the
> > screen saver displays. Through all this, though, it's still so worth
> > it.
>

> Yes, it requires more CPU cycles if you use raster mode. Does it also
> slow down your console if you are running under text mode? I hope
> not :-)
>

If I'm in text mode it's fine, but of course low-res. When I'm in
raster mode I think it's maybe slower than it needs to be? (Slower
than similar situations in Linux, for instance.) Also, if I have some
terminals in text and some in raster, the switch between them is long.
That's hardly a problem by itself, though, as I rarely run mixed
terminal resolutions.

[Xin LI]

Hi, Eric,

在 2005-05-25三的 13:28 +0900，Eric Kjeldergaard写道：

> 2005/5/23, Xin LI <del...@frontfree.net>:
> > Hi, Jeremie,
> >

> > $B:_ (B 2005-05-23 $B0lE* (B 02:38 +0200 $B!$ (BJeremie Le Hen $B<LF;!' (B

> > [snip]
> > > One question however : is it supposed to consume more CPU than classical
> > > non-VESA text mode ?
> >
> > I think so, it should consume more CPU than classical text mode console
> > since it draws characters, rather than giving the responsibility to the
> > video card. A possible optimization would be to map the video card
> > memory into the space.
>
> Tested on my Thinkpad R40 : Radeon 7500. Is it supposed to consume a
> LOT of cpu? Perhaps there's something funny with -O2 or similar
> because some things are VERY slow. I have not, however, noticed any
> major bugs, but screen redraws will take ~1 second if the screen is
> not cleared and thus causes powerd to kick my processor up to full
> speed often. Also, the screensaver (logo_saver) seems to take a while
> to display. The screen goes black for 10 - 15 seconds before the
> screen saver displays. Through all this, though, it's still so worth
> it.

Yes, it requires more CPU cycles if you use raster mode. Does it also

slow down your console if you are running under text mode? I hope
not :-)

Cheers,
--
Xin LI <delphij delphij net> http://www.delphij.net/

[Xin LI]

在 2005-05-25三的 14:59 +0900，Eric Kjeldergaard写道：
> 2005/5/25, Xin LI <del...@delphij.net>:

> If I'm in text mode it's fine, but of course low-res. When I'm in
> raster mode I think it's maybe slower than it needs to be? (Slower
> than similar situations in Linux, for instance.) Also, if I have some
> terminals in text and some in raster, the switch between them is long.
> That's hardly a problem by itself, though, as I rarely run mixed
> terminal resolutions.

Yes. Someone has suggested that we should mmap the display buffer
directly to gain good performance, but I do not have enough to implement
it at this time :-(

[Eric Anderson]

I noticed that changing to 16bit (instead of 32 or 24) helped a lot.

Eric

--
------------------------------------------------------------------------
Eric Anderson Sr. Systems Administrator Centaur Technology
A lost ounce of gold may be found, a lost moment of time never.
------------------------------------------------------------------------

_______________________________________________

[Kevin Oberman]

I have now completely updated my system (IBM T30 with Radeon M7 7500
graphics) to current with the patches applied. I am loading vesa a boot
time.

I see all of the graphics modes (about 30 of them), but am unable to
enable them. I get either:

vidcontrol: Setting video mode: Inappropriate ioctl for device
or

vidcontrol: cannot activate raster mode: Inappropriate ioctl for device

depending on the mode selected. If I get the first message, it is almost
instantaneous. If I get the second, the display blanks for several
seconds before the message comes out.

Any suggestions Should I build the kernel with vesa as opposed to loading
the module?

--
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: obe...@es.net Phone: +1 510 486-8634

[Eric Anderson]

Kevin Oberman wrote:
> I have now completely updated my system (IBM T30 with Radeon M7 7500
> graphics) to current with the patches applied. I am loading vesa a boot
> time.
>
> I see all of the graphics modes (about 30 of them), but am unable to
> enable them. I get either:
> vidcontrol: Setting video mode: Inappropriate ioctl for device
> or
> vidcontrol: cannot activate raster mode: Inappropriate ioctl for device
>
> depending on the mode selected. If I get the first message, it is almost
> instantaneous. If I get the second, the display blanks for several
> seconds before the message comes out.
>
> Any suggestions Should I build the kernel with vesa as opposed to loading
> the module?

I'm using the vesa module, and it works fine. Did you add the
SC_PIXEL_MODE line to your kernel config before rebuilding?

Eric

--
------------------------------------------------------------------------
Eric Anderson Sr. Systems Administrator Centaur Technology
A lost ounce of gold may be found, a lost moment of time never.
------------------------------------------------------------------------

[Kevin Oberman]

> Date: Wed, 25 May 2005 13:25:43 -0500
> From: Eric Anderson <ande...@centtech.com>

>
> Kevin Oberman wrote:
> > I have now completely updated my system (IBM T30 with Radeon M7 7500
> > graphics) to current with the patches applied. I am loading vesa a boot
> > time.
> >
> > I see all of the graphics modes (about 30 of them), but am unable to
> > enable them. I get either:
> > vidcontrol: Setting video mode: Inappropriate ioctl for device
> > or
> > vidcontrol: cannot activate raster mode: Inappropriate ioctl for device
> >
> > depending on the mode selected. If I get the first message, it is almost
> > instantaneous. If I get the second, the display blanks for several
> > seconds before the message comes out.
> >
> > Any suggestions Should I build the kernel with vesa as opposed to loading
> > the module?
>
> I'm using the vesa module, and it works fine. Did you add the
> SC_PIXEL_MODE line to your kernel config before rebuilding?

Thanks, Eric.

I'll be away from my desk for a bit to get lunch and have "moron"
tattooed on my forehead. :-)

How many FreeBSD systems do I have that I have SC_PIXEL_MODE on? Almost
all of them. I guess I pulled it from this system because it didn't
support a graphics console and then I forgot all about it.

--
R. Kevin Oberman, Network Engineer
Energy Sciences Network (ESnet)
Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab)
E-mail: obe...@es.net Phone: +1 510 486-8634

[Dag-Erling Smørgrav]

"Alexandre \"Sunny\" Kovalenko" <Alex.Ko...@verizon.net> writes:
> I have observed some odd behavior when X display becomes garbled if USB
> stack is loaded and USB keyboard is attached after user has logged into
> X desktop (Gnome in my case). I am setting MODE_280 (1024x768x32) in
> rc.conf using 'allscreens_flags'.

In recent -CURRENT, plugging in a USB keyboard or mouse triggers
'/etc/rc.d/syscons restart' which applies allscreens_flags to all
active consoles, including the one X runs on. This is not a bug in
delphij's code; /etc/rc.d/syscons should skip consoles that are in use
by X.

DES
--
Dag-Erling Smørgrav - d...@des.no

[Dag-Erling Smørgrav]

Eric Anderson <ande...@centtech.com> writes:
> I noticed that changing to 16bit (instead of 32 or 24) helped a lot.

..because more pixels fit in a single 64 kB page, so the console code
doesn't have to switch pages as much while redrawing the screen.
Switching pages requires switching to virtual x86 mode (stalling the
CPU and invalidating the cache) to invoke the VESA BIOS. On graphic
adapters with linear framebuffer support (pretty much all of them
today), you can map the entire framebuffer into memory to avoid
paging, but our VESA driver doesn't know how to do that.

DES
--
Dag-Erling Smørgrav - d...@des.no

[Dag-Erling Smørgrav]

Jeremie Le Hen <jer...@le-hen.org> writes:
> Nearly perfect :-). I use the fade saver and when I woke up this morning,
> going back from the screen saver turned the VESA console text into blue.
> Not the whole text, just the non-brilliant one. This is not the case on
> non-VESA consoles.

The fade screensaver plays games with the palette; syscons should
always assume that the screensaver may have altered the palette, and
restore it when the screensaver stops, but apparently it doesn't.

DES
--
Dag-Erling Smørgrav - d...@des.no

[Antony T Curtis]

On Thu, 2005-05-26 at 22:28 +0200, Dag-Erling Smørgrav wrote:
> Eric Anderson <ande...@centtech.com> writes:
> > I noticed that changing to 16bit (instead of 32 or 24) helped a lot.
>

> ...because more pixels fit in a single 64 kB page, so the console code

> doesn't have to switch pages as much while redrawing the screen.
> Switching pages requires switching to virtual x86 mode (stalling the
> CPU and invalidating the cache) to invoke the VESA BIOS. On graphic
> adapters with linear framebuffer support (pretty much all of them
> today), you can map the entire framebuffer into memory to avoid
> paging, but our VESA driver doesn't know how to do that.

Strange, I thought that the VESA driver did know how to do that. I
recall years ago writing a driver for XFree86 3.3 which used the FreeBSD
VESA driver to switch video mode and set up a linear frame buffer.

I have even found the ancient email with it...
http://listserver.uk.freebsd.org/pipermail/freebsd-users/2001-May/003629.
html

--
Antony T Curtis, BSc. UNIX, Linux, *BSD, Networking
antony....@ntlworld.com C++, J2EE, Perl, MySQL, Apache
IT Consultancy.

[Vladimir Grebenschikov]

В вс, 22/05/2005 в 19:26 +0800, Xin LI пишет:

> Dear -CURRENT users,
>
> I would like to solicit a test of the following patchset which is based
> on DragonFly's changes, against -CURRENT, to bring high resolution consol
e
> support to FreeBSD. The current patchset can be considered as "BETA" and
> I would commit it if there is no complain about this patchset in the next
> week.

[ ... cut ... ]

> Please let me know if anything strange happens; While I have been runnin
g

> with the patch for a while, I would still be happy if you will report tha
t
> it works :-)

Tried fresh 6-CURRENT, all seems ok, but,
switching console to pixel-mode 1400x1050 screen takes about 1-2 sec, I
guess it is too much. (it happens in both cases

Also, I had freezed box when switching from X to console some times.

> Cheers,

--
Vladimir B. Grebenchikov
vo...@fbsd.ru

[Andre Guibert de Bruet]

On Wed, 8 Jun 2005, Vladimir Grebenschikov wrote:

> ? ??, 22/05/2005 ? 19:26 +0800, Xin LI ?????:

>>
>> I would like to solicit a test of the following patchset which is based
>> on DragonFly's changes, against -CURRENT, to bring high resolution console
>> support to FreeBSD. The current patchset can be considered as "BETA" and
>> I would commit it if there is no complain about this patchset in the next
>> week.
> [ ... cut ... ]
>> Please let me know if anything strange happens; While I have been running
>> with the patch for a while, I would still be happy if you will report that
>> it works :-)
>
> Tried fresh 6-CURRENT, all seems ok, but,
> switching console to pixel-mode 1400x1050 screen takes about 1-2 sec, I
> guess it is too much. (it happens in both cases
>
> Also, I had freezed box when switching from X to console some times.

Let me guess... It's a laptop screen or an LCD panel?

Andy

/* Andre Guibert de Bruet * 6f43 6564 7020 656f 2e74 4220 7469 6a20 */
/* Code poet / Sysadmin * 636f 656b 2e79 5320 7379 6461 696d 2e6e */
/* GSM: +1 734 846 8758 * 5520 494e 2058 6c73 7565 6874 002e 0000 */
/* WWW: siliconlandmark.com * Tormenting bytes since 1980. */

[Vladimir Grebenschikov]

В ср, 08/06/2005 в 14:56 -0400, Andre Guibert de Bruet пише
т:

> On Wed, 8 Jun 2005, Vladimir Grebenschikov wrote:
>
> > ? ??, 22/05/2005 ? 19:26 +0800, Xin LI ?????:
> >>
> >> I would like to solicit a test of the following patchset which is base
d
> >> on DragonFly's changes, against -CURRENT, to bring high resolution con
sole
> >> support to FreeBSD. The current patchset can be considered as "BETA"
and
> >> I would commit it if there is no complain about this patchset in the n
ext
> >> week.
> > [ ... cut ... ]
> >> Please let me know if anything strange happens; While I have been run
ning
> >> with the patch for a while, I would still be happy if you will report
that
> >> it works :-)
> >
> > Tried fresh 6-CURRENT, all seems ok, but,
> > switching console to pixel-mode 1400x1050 screen takes about 1-2 sec, I
> > guess it is too much. (it happens in both cases
> >
> > Also, I had freezed box when switching from X to console some times.
>
> Let me guess... It's a laptop screen or an LCD panel?

Yes, exactly, it is sony vzio z1.

(II) RADEON(0): Panel ID string: Samsung LTN150P1-L02
(II) RADEON(0): Panel Size from BIOS: 1400x1050
(II) RADEON(0): BIOS provided dividers will be used.

> Andy
>
> /* Andre Guibert de Bruet * 6f43 6564 7020 656f 2e74 4220 7469 6a20 */
> /* Code poet / Sysadmin * 636f 656b 2e79 5320 7379 6461 696d 2e6e */
> /* GSM: +1 734 846 8758 * 5520 494e 2058 6c73 7565 6874 002e 0000 */
> /* WWW: siliconlandmark.com * Tormenting bytes since 1980. */
>

--
Vladimir B. Grebenchikov
vo...@fbsd.ru

[Andre Guibert de Bruet]

On Wed, 8 Jun 2005, Vladimir Grebenschikov wrote:

> ? ??, 08/06/2005 ? 14:56 -0400, Andre Guibert de Bruet ?????:

>> On Wed, 8 Jun 2005, Vladimir Grebenschikov wrote:
>>> ? ??, 22/05/2005 ? 19:26 +0800, Xin LI ?????:
>>>>
>>>> I would like to solicit a test of the following patchset which is based
>>>> on DragonFly's changes, against -CURRENT, to bring high resolution console
>>>> support to FreeBSD. The current patchset can be considered as "BETA" and
>>>> I would commit it if there is no complain about this patchset in the next
>>>> week.
>>> [ ... cut ... ]
>>>> Please let me know if anything strange happens; While I have been running
>>>> with the patch for a while, I would still be happy if you will report that
>>>> it works :-)
>>>
>>> Tried fresh 6-CURRENT, all seems ok, but,
>>> switching console to pixel-mode 1400x1050 screen takes about 1-2 sec, I
>>> guess it is too much. (it happens in both cases
>>>
>>> Also, I had freezed box when switching from X to console some times.
>>
>> Let me guess... It's a laptop screen or an LCD panel?
>
> Yes, exactly, it is sony vzio z1.
>
> (II) RADEON(0): Panel ID string: Samsung LTN150P1-L02
> (II) RADEON(0): Panel Size from BIOS: 1400x1050
> (II) RADEON(0): BIOS provided dividers will be used.

Most laptop LCDs and cheaper desktop panels take a while (The dreaded
second or two) to switch resolutions. Try the patch with an external crt
monitor plugged in and display mirroring enabled to see the difference for
yourself (Or simply try it on a desktop with a radeon card and a crt).

Andy

/* Andre Guibert de Bruet * 6f43 6564 7020 656f 2e74 4220 7469 6a20 */
/* Code poet / Sysadmin * 636f 656b 2e79 5320 7379 6461 696d 2e6e */
/* GSM: +1 734 846 8758 * 5520 494e 2058 6c73 7565 6874 002e 0000 */
/* WWW: siliconlandmark.com * Tormenting bytes since 1980. */

[Vladimir Grebenschikov]

В ср, 08/06/2005 в 17:29 -0400, Andre Guibert de Bruet пише
т:

I have tried to switch from X or from pixel-mode console to usual text
mode console (80x25), and it does not pause in in this case. But it
pauses when switched back. Is it problem of hardware or our pixel-mode
console ?

> Andy
>
> /* Andre Guibert de Bruet * 6f43 6564 7020 656f 2e74 4220 7469 6a20 */
> /* Code poet / Sysadmin * 636f 656b 2e79 5320 7379 6461 696d 2e6e */
> /* GSM: +1 734 846 8758 * 5520 494e 2058 6c73 7565 6874 002e 0000 */
> /* WWW: siliconlandmark.com * Tormenting bytes since 1980. */

--
Vladimir B. Grebenschikov
vo...@fbsd.ru

[Andre Guibert de Bruet]

On Thu, 9 Jun 2005, Vladimir Grebenschikov wrote:

> ? ??, 08/06/2005 ? 17:29 -0400, Andre Guibert de Bruet ?????:

>> On Wed, 8 Jun 2005, Vladimir Grebenschikov wrote:
>>> ? ??, 08/06/2005 ? 14:56 -0400, Andre Guibert de Bruet ?????:
>>>> On Wed, 8 Jun 2005, Vladimir Grebenschikov wrote:
>>>>> ? ??, 22/05/2005 ? 19:26 +0800, Xin LI ?????:
>>>>>>
>>>>>> I would like to solicit a test of the following patchset which is based
>>>>>> on DragonFly's changes, against -CURRENT, to bring high resolution console
>>>>>> support to FreeBSD. The current patchset can be considered as "BETA" and
>>>>>> I would commit it if there is no complain about this patchset in the next
>>>>>> week.
>>>>> [ ... cut ... ]
>>>>>> Please let me know if anything strange happens; While I have been running

>>>>>> with the patch for a while, I would still be happy if you will report that

>>>>>> it works :-)
>>>>>
>>>>> Tried fresh 6-CURRENT, all seems ok, but,
>>>>> switching console to pixel-mode 1400x1050 screen takes about 1-2 sec, I
>>>>> guess it is too much. (it happens in both cases
>>>>>
>>>>> Also, I had freezed box when switching from X to console some times.
>>>>
>>>> Let me guess... It's a laptop screen or an LCD panel?
>>>
>>> Yes, exactly, it is sony vzio z1.
>>>
>>> (II) RADEON(0): Panel ID string: Samsung LTN150P1-L02
>>> (II) RADEON(0): Panel Size from BIOS: 1400x1050
>>> (II) RADEON(0): BIOS provided dividers will be used.
>>
>> Most laptop LCDs and cheaper desktop panels take a while (The dreaded
>> second or two) to switch resolutions. Try the patch with an external crt
>> monitor plugged in and display mirroring enabled to see the difference for
>> yourself (Or simply try it on a desktop with a radeon card and a crt).
>
> I have tried to switch from X or from pixel-mode console to usual text
> mode console (80x25), and it does not pause in in this case. But it
> pauses when switched back. Is it problem of hardware or our pixel-mode
> console ?

With the "normal" console, the drawing of the characters is left to the
display device. In raster mode, we have to do the drawing. I see a very
tiny delay on a CRT with the VESA console. Your display hardware is
probably resetting itself as it enters a VESA display mode.

Andy

/* Andre Guibert de Bruet * 6f43 6564 7020 656f 2e74 4220 7469 6a20 */
/* Code poet / Sysadmin * 636f 656b 2e79 5320 7379 6461 696d 2e6e */
/* GSM: +1 734 846 8758 * 5520 494e 2058 6c73 7565 6874 002e 0000 */
/* WWW: siliconlandmark.com * Tormenting bytes since 1980. */

[Vladimir Grebenschikov]

В ср, 08/06/2005 в 17:29 -0400, Andre Guibert de Bruet пише
т:

I have got a maximum waiting for switching from X to console (X screen
disappeared very quick) - about 10 secs, probably it related to some
disk activity, can syscon pages be swapped ?

> Andy
>
> /* Andre Guibert de Bruet * 6f43 6564 7020 656f 2e74 4220 7469 6a20 */
> /* Code poet / Sysadmin * 636f 656b 2e79 5320 7379 6461 696d 2e6e */
> /* GSM: +1 734 846 8758 * 5520 494e 2058 6c73 7565 6874 002e 0000 */
> /* WWW: siliconlandmark.com * Tormenting bytes since 1980. */

--
Vladimir B. Grebenschikov
vo...@fbsd.ru

[Andre Guibert de Bruet]

On Fri, 10 Jun 2005, Vladimir Grebenschikov wrote:
> ? ??, 08/06/2005 ? 17:29 -0400, Andre Guibert de Bruet ?????:

>> On Wed, 8 Jun 2005, Vladimir Grebenschikov wrote:
>>> ? ??, 08/06/2005 ? 14:56 -0400, Andre Guibert de Bruet ?????:
>>>>

>>>> Let me guess... It's a laptop screen or an LCD panel?
>>>
>>> Yes, exactly, it is sony vzio z1.
>>>
>>> (II) RADEON(0): Panel ID string: Samsung LTN150P1-L02
>>> (II) RADEON(0): Panel Size from BIOS: 1400x1050
>>> (II) RADEON(0): BIOS provided dividers will be used.
>>
>> Most laptop LCDs and cheaper desktop panels take a while (The dreaded
>> second or two) to switch resolutions. Try the patch with an external crt
>> monitor plugged in and display mirroring enabled to see the difference for
>> yourself (Or simply try it on a desktop with a radeon card and a crt).
>
> I have got a maximum waiting for switching from X to console (X screen
> disappeared very quick) - about 10 secs, probably it related to some
> disk activity, can syscon pages be swapped ?

Wow. 10 seconds goes beyond the limits of reasonable.

I would not expect to see syscons pages being swapped, even under extreme
memory pressure. How much memory is available in this system? Could you
make a recent boot -v (With the patch) and the kernel config available?

Andy

/* Andre Guibert de Bruet * 6f43 6564 7020 656f 2e74 4220 7469 6a20 */
/* Code poet / Sysadmin * 636f 656b 2e79 5320 7379 6461 696d 2e6e */
/* GSM: +1 734 846 8758 * 5520 494e 2058 6c73 7565 6874 002e 0000 */
/* WWW: siliconlandmark.com * Tormenting bytes since 1980. */

_______________________________________________