gmane.linux.console

Re: wishlist: vnc framebuffer device?

richard -rw- weinberger — 2012-06-18T08:13:42

Start the VNC server in your initrd and make sure that it gets
not killed... :-)

Re: wishlist: vnc framebuffer device?

Harald Dunkel — 2012-06-18T06:59:51

Hi Richard,

On 06/17/12 12:13, richard -rw- weinberger wrote:

If it can run in user space, then thats fine with me. But I
would guess the pseudo framebuffer device itself (without the
networking, authentication and encryption stuff) has to
reside in the kernel.

It is very important to me to get access to the VNC console
very early in the boot procedure, e.g. if there is a fsck
asking for help, or if a badly configured root device drops
me on busybox.

For qemu/kvm hosts (and others) it is very convenient to
access the console via VNC. For "real" hosts I am restricted
to SOL or some remote management hardware module providing
a web interface.

It would be very nice to get an improvement here.


Regards

Harri
--
To unsubscribe from this list: send the line "unsubscribe linux-console" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: wishlist: vnc framebuffer device?

Veyrdite — 2012-06-17T08:57:18

Hey Harald,

 > To make a headless system "less headless", would it be possible
 > to integrate a vnc framebuffer device into the kernel?

VNC as I understand is more suitable for graphical environments.  For
just text SSH or even telnet/netcat would be more practical.

 > The idea is to have a vnc server instead of a local screen and
 > keyboard to show the boot output and to provide a console login
 > on /dev/tty{1..6}. It would be pretty similar to qemu. No need
 > for fancy graphics, of course. The IP address might either be
 > obtained using DHCP, or it might use an IP address/netmask
 > given on the kernel command line.

As I understand it most init implementations log all of their messages
to a file in /var/log, so you can view them all post-bootup once you
have vnc'd or into the box.  This would be the simplest and most
foolproof solution, but may not be what you want.

If you are going to send your messaged over a trusted LAN or network
( ie not the internet ) then I'd go with the 'netconsole' modul

wishlist: vnc framebuffer device?

Harald Dunkel — 2012-06-16T11:05:24

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi folks,

To make a headless system "less headless", would it be possible
to integrate a vnc framebuffer device into the kernel?

The idea is to have a vnc server instead of a local screen and
keyboard to show the boot output and to provide a console login
on /dev/tty{1..6}. It would be pretty similar to qemu. No need
for fancy graphics, of course. The IP address might either be
obtained using DHCP, or it might use an IP address/netmask
given on the kernel command line.

I understand that authentication might be an issue here.

Hopefully this isn't one of the oh-no-not-again questions. I
haven't seen it mentioned on the kernel or linux-console
mailing lists before.


Regards

Harri
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAk/caG4ACgkQUTlbRTxpHjf8EwCZAZ0H17WYyEwJB3QgCNjazY2O
3NMAn2e0dJa3sbiZr33nY11m1g0zm0j3
=MANA
-----END PGP SIGNATURE-----
--
To unsubscribe from this list: send the line "unsubscribe linux-console" in
the bod

Re: Different scan code behavior in X and console

郭晓峰 — 2012-01-15T07:49:31

OK, I got it. Ctrl-PageDown is remapped by Mac and Windows, it works in Linux.

Please skip this problem, it doesn't related to Linux.

On Sat, Jan 14, 2012 at 4:52 PM, 郭晓峰 <lamuguo< at >gmail.com> wrote:
--
To unsubscribe from this list: send the line "unsubscribe linux-console" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Different scan code behavior in X and console

郭晓峰 — 2012-01-15T00:52:58

Hi there,

Sorry to bother. Not sure whether it is correct to post this question
to the mail list, but can't find a suitable linux console user mail
list for discussing this. If you have good mail list to suggest,
please help me to forward. Thanks!

The question is: I tried to make my emacs have the same key response
on both X and console (ssh pts). However, I can't find scan code for
"Ctrl-PageDown" in console mode. I attached the code for testing the
scan code, and below is different behavior in X and console:

============= X ===========
Press a Key 338   // Just type <PageDown>
Press a Key 27
Press a Key 91
Press a Key 54
Press a Key 59
Press a Key 53
Press a Key 126  // 6-chars for <Ctrl-PageDown>
============ Console =========
Press a Key 338  // Same for <PageDown>
Press a Key         // No response for <Ctrl-PageDown>

Any idea on this? Greatly appreciate your replies, your suggested
readings, and so on!

Best Regards,
Lamu Guo

=============Below is text of the code, for easily reading to skip
attac

Need advice on performant text-mode output API

Andrey Utkin — 2011-12-24T15:57:56

Hi. I develop the program that visualizes disk checking process.
Similarly to known DOS program, MHDD.
To get the idea, you can find screencasts of its usage on Youtube.
Or look at my program's screenshot:
http://cloud.github.com/downloads/krieger-od/whdd/whdd_screenshot5.png
So i need to update big zone at left, and stats in top right corner.
The point is that it can be ~1000 blocks processed per second,
although it is ok to render them each Nth time, like at each 10-50
blocks processed.
Currently i use ncurses, and its performance is unacceptable, the
screen blinks awfully, because it prints whole screen of chars on
refresh.

I ask for directing me to any sufficiently performant libs/API, to
replace ncurses.
It would be ok, and even nice, if it is plain text mode (80x25, 16
colors), without any overhead of representing my chars as graphical
points.
It would be _very_ nice, if that API provide 'windows' model in terms
of ncurses, to work with rectangular pieces.
No OS portability is required. Linux only is

Re: [PATCH] drivers/tty: don't use the byte channel handle as a parameter in ehv_bytechan.c

Tabi Timur-B04825 — 2011-09-23T01:11:55

It does not, and I see why now.  Looks like the internal tree is not in 
sync after all.

I will post a V2 shortly.

Re: [PATCH] drivers/tty: don't use the byte channel handle as a parameter in ehv_bytechan.c

Greg KH — 2011-09-22T23:28:28

There is no public one due to kernel.org being down.

Does your patch apply to linux-next?
--
To unsubscribe from this list: send the line "unsubscribe linux-console" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] drivers/tty: don't use the byte channel handle as a parameter in ehv_bytechan.c

Greg KH — 2011-09-22T23:06:40

This patch doesn't apply at all to my tty tree, what was it made
against?

confused,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-console" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH] drivers/tty: don't use the byte channel handle as a parameter in ehv_bytechan.c

Timur Tabi — 2011-09-20T18:26:57

The ePAPR hypervisor byte channel console driver only supports one byte
channel as a console, and the byte channel handle is stored in a global
variable.  It doesn't make any sense to pass that handle as a parameter
to the console functions, since these functions already have access to the
global variable.

This change also fixes this compilation warning on a 64-bit kernel:

  CC      drivers/tty/ehv_bytechan.o
drivers/tty/ehv_bytechan.c: In function 'ehv_bc_console_write':
drivers/tty/ehv_bytechan.c:289:24: warning: cast from pointer to integer of different size
drivers/tty/ehv_bytechan.c: In function 'ehv_bc_console_init':
drivers/tty/ehv_bytechan.c:355:24: warning: cast to pointer from integer of different size

This warning is because the driver is converting the integer byte channel
handle to/from the void* 'data' field of struct console.  Rather than fix
the warning, we just eliminate the code altogether.

Signed-off-by: Timur Tabi <timur< at >freescale.com>
---
 drivers/tty/ehv_bytechan.c |    7 ++-----
 1

Re: [PATCH] [v3] tty/powerpc: introduce the ePAPR embedded hypervisor byte channel driver

Tabi Timur-B04825 — 2011-07-22T19:00:40

Greg,

I just want to make sure you haven't forgotten this patch.  Will you
be picking it up for 3.1?

[PATCH] [v3] tty/powerpc: introduce the ePAPR embedded hypervisor byte channel driver

Timur Tabi — 2011-07-09T00:06:12

The ePAPR embedded hypervisor specification provides an API for "byte
channels", which are serial-like virtual devices for sending and receiving
streams of bytes.  This driver provides Linux kernel support for byte
channels via three distinct interfaces:

1) An early-console (udbg) driver.  This provides early console output
through a byte channel.  The byte channel handle must be specified in a
Kconfig option.

2) A normal console driver.  Output is sent to the byte channel designated
for stdout in the device tree.  The console driver is for handling kernel
printk calls.

3) A tty driver, which is used to handle user-space input and output.  The
byte channel used for the console is designated as the default tty.

Signed-off-by: Timur Tabi <timur< at >freescale.com>
---
 arch/powerpc/include/asm/udbg.h |    1 +
 arch/powerpc/kernel/udbg.c      |    2 +
 drivers/tty/Kconfig             |   34 ++
 drivers/tty/Makefile            |    1 +
 drivers/tty/ehv_bytechan.c      |  888 ++++++++++++++++++++++++++++++++++++++

Re: tty/powerpc: introduce the ePAPR embedded hypervisor byte channel driver

Greg KH — 2011-07-08T22:29:51

Don't ignore it, that's the one :)
--
To unsubscribe from this list: send the line "unsubscribe linux-console" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: tty/powerpc: introduce the ePAPR embedded hypervisor byte channel driver

Timur Tabi — 2011-07-08T22:15:47

Um, where exactly is the tty-next tree?  The only thing I see that looks like it
is this:

git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty-2.6.git

But the description of this tree says, "junk tree, please ignore".

Re: tty/powerpc: introduce the ePAPR embedded hypervisor byte channel driver

Timur Tabi — 2011-07-08T22:12:42

I shall take care of that right now.

Re: tty/powerpc: introduce the ePAPR embedded hypervisor byte channel driver

Greg KH — 2011-07-08T22:06:54

Doesn't apply at all to the tty-next tree, so I can't apply it here :(

--
To unsubscribe from this list: send the line "unsubscribe linux-console" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 6/7] [v2] tty/powerpc: introduce the ePAPR embedded hypervisor byte channel driver

Tabi Timur-B04825 — 2011-07-03T01:43:52

Greg, would you please pick up this patch for 3.1?  Patches 1-5 are
already queued through the PowerPC tree.

Thank you.

The patch is available here if you need to download it:
http://patchwork.ozlabs.org/patch/96443/

Re: [PATCH 7/7] [v6] drivers/virt: introduce Freescale hypervisor management driver

Arnd Bergmann — 2011-07-01T17:12:49

I'd say merge it  through the powerpc tree, and list yourself for
the driver, but not the entire directory.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-console" in
the body of a message to majordomo< at >vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 7/7] [v6] drivers/virt: introduce Freescale hypervisor management driver

Tabi Timur-B04825 — 2011-07-01T01:18:15

....

So I've made the changes that people have asked for, and Arnd has
acked this driver.  Who's going to pick it up?  Who will be the
maintainer for drivers/virt?  I'd really like to see this driver in
3.1, and there's not much time left.

Re: [PATCH 6/7] [v2] tty/powerpc: introduce the ePAPR embedded hypervisor byte channel driver

Timur Tabi — 2011-06-22T15:23:32

I know you guys are busy, but can I get an ACK or two on this patch, if there
are no issues with it?  It's the only one of the seven that doesn't have one.  I
think v2 has addressed all of the concerns raised on version 1.