It is currently Mon Aug 21, 2017 2:46 pm

All times are UTC - 7 hours





Post new topic Reply to topic  [ 11 posts ] 
Author Message
PostPosted: Wed Jun 15, 2016 6:27 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7153
Location: Chexbres, VD, Switzerland
Just trying to make a new post usking w3m text-mode/command line web browser.

The editing interface uses the vim edit mode, which I am unfortunately not familiar with. However it can, somehow, include graphics in text mode, I do not know by which technical miracle.


Top
 Profile  
 
PostPosted: Wed Jun 15, 2016 11:30 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6042
Location: Seattle
Under X11, it gets hold of the X11 handle for the X terminal that it's in, and then uses a call to XCopyArea to blit the image into the right place in the window containing the terminal.

Under windows, it instead uses a call to Gdiplus::Graphics::DrawCachedBitmap


Top
 Profile  
 
PostPosted: Wed Jun 15, 2016 1:42 pm 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7153
Location: Chexbres, VD, Switzerland
Well it was under neither, just under the real command line (with no graphical interface service started).


Top
 Profile  
 
PostPosted: Wed Jun 15, 2016 1:44 pm 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6042
Location: Seattle
Well, there's the framebuffer method also. That's by far the least magical.


Top
 Profile  
 
PostPosted: Fri Jun 17, 2016 2:38 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7153
Location: Chexbres, VD, Switzerland
But how come there's a frameuffer in console mode? I tought console mode had a text buffer and graphics mode a framebuffer (at least that's what makes most sense to me).


Top
 Profile  
 
PostPosted: Fri Jun 17, 2016 3:28 am 
Offline

Joined: Tue Oct 06, 2015 10:16 am
Posts: 496
What you used wasn't likely a 80x25 VGA text mode, but a 1920x1080 KMS framebuffer mode (or whatever your screen is at). Was the font as big as in the old BIOS screens? If it wasn't, you were in a framebuffer mode.


Top
 Profile  
 
PostPosted: Fri Jun 17, 2016 10:50 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6042
Location: Seattle
We've long since stopped using the video card's native text mode hardware. The last time it was really useful was with SVGATextMode's final release 16 years ago; since then we've mostly grown framebuffer-based text modes. (And even now, that specific mechanism is mostly being deprecated in favor of the Kernel ModeSetting infrastructure)

Version 3 and up of VESA VBE has allowed deprecating all sorts of pure-VGA compatibility things. I wouldn't be surprised if modern video cards can't be configured to to draw a 16 color planar mode, and if the mode 3h text mode is a vestigial stub that does something really weird underneath.


Top
 Profile  
 
PostPosted: Wed Jun 22, 2016 2:18 am 
Offline
User avatar

Joined: Fri Nov 12, 2004 2:49 pm
Posts: 7153
Location: Chexbres, VD, Switzerland
lidnariq wrote:
We've long since stopped using the video card's native text mode hardware.

Sure, that's no big surprise, but form a software p.o.w. it doesn't matter how the text mode is rendered in hardware, if this is done by a geniune chip or a piece of firmware that renders it to a modern framebuffer-based system.

So that means lynx just abuses the firmware underneath and uses it to write images to the framebuffer?


Top
 Profile  
 
PostPosted: Wed Jun 22, 2016 2:32 am 
Offline
User avatar

Joined: Sun Sep 19, 2004 9:28 pm
Posts: 3192
Location: Mountain View, CA, USA
Yup, correct -- as I understand it, they just interact with the framebuffer "directly" (through the kernel in some fashion). There's even w3m-img that apparently will render images/etc. using the same methodology.

There are many of us who still prefer the old classic 80x25 text mode and not use framebuffers -- I find the latter to be incredibly slow during screen scrolling of text (dmesg output on Ubuntu is a good example), even on systems with dedicated framebuffers. But then again, I also don't use *IX machines as desktops/workstations, so my desire for an actual framebuffer is virtually nil (I'm of the "if you're gonna go that far, might as well just run X.org" stance).


Top
 Profile  
 
PostPosted: Wed Jun 22, 2016 9:58 am 
Offline

Joined: Sun Apr 13, 2008 11:12 am
Posts: 6042
Location: Seattle
Bregalad wrote:
lidnariq wrote:
We've long since stopped using the video card's native text mode hardware.
Sure, that's no big surprise, but from a software p.o.v. it doesn't matter how the text mode is rendered in hardware, if this is done by a genuine chip or a piece of firmware that renders it to a modern framebuffer-based system.
At least in linux, the in-kernel VT100 emulator transparently updates the contents of the framebuffer in response to writes to /dev/tty. i.e. w3m thinks it's interacting with a dumb terminal, but w3m-img says "oh, hey, I'm in a framebuffer, let me go scribble all over everything" ... i.e. the point is that w3m-img breaks the abstraction.

Quote:
So that means lynx just abuses the firmware underneath and uses it to write images to the framebuffer?
w3m, sure? Not lynx or or the other ones that are just in the emulated text mode.

koitsu wrote:
framebuffers -- I find the latter to be incredibly slow during screen scrolling of text (dmesg output on Ubuntu is a good example), even on systems with dedicated framebuffers.
Before the KMS mess (linux's democratizing "no one can have a good interface, everyone must use the same awful one"), many of the in-kernel framebuffer drivers had hardware acceleration that made it feel as fast as the native text mode hardware.

Of course, the useful not-KMS drivers also date to when we had more than three serious video card vendors.


Top
 Profile  
 
PostPosted: Sun Jul 10, 2016 6:21 pm 
Offline
User avatar

Joined: Mon Feb 07, 2011 12:46 pm
Posts: 911
The better way to draw pictures on a terminal would be to use Sixel graphics (as far as I know, only xterm currently implements this feature).

_________________
.


Top
 Profile  
 
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 11 posts ] 

All times are UTC - 7 hours


Who is online

Users browsing this forum: No registered users and 1 guest


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group