linux-fbdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnd Bergmann <arnd@arndb.de>
To: Michal Januszewski <spock@gentoo.org>
Cc: linux-kernel@vger.kernel.org, linux-fbdev-devel@lists.sourceforge.net
Subject: Re: [announce 7/7] fbsplash - documentation
Date: Wed, 9 Mar 2005 16:40:09 +0100	[thread overview]
Message-ID: <200503091640.10421.arnd@arndb.de> (raw)
In-Reply-To: <20050309020527.GA20294@spock.one.pl>

On Middeweken 09 März 2005 03:05, Michal Januszewski wrote:
> On Wed, Mar 09, 2005 at 01:17:11AM +0100, Arnd Bergmann wrote:
> change_console()
> complete_change_console()
> switch_screen() == redraw_screen()
> con_switch() == fbcon_switch()
> 
> From inside fbcon_switch(), we need to call the splash helper to get a
> new picture for the theme 'bar' which is used on tty2. The splash helper
> does an ioctl and we're back in the kernel.. with the console semaphore
> already held.

Ok, I now saw that you call call_usermodehelper with wait==1. Why is that
necessary? If you don't wait there, you don't need any hacks around the
console semaphore, because the helper will simply wait for change_console
to finish.
 
> What are the alternatives to the ioctl? A relatively clean way of
> feeding the data back to the kernel would be using sysfs. However, to
> make it sane we would have to export the various components of struct
> vc_splash in /sys/class/tty/tty<x> (otherwise, we would probabky have
> to pass aggreaget data types through a sysfs entry -- something that is
> IMO much worse than an ioctl). That however could be a little
> problematic -- tty_class is currently defined as a class_simple.
> To add entries other than the standard 'dev' we would have to define a
> completely new class, right? That sounds like a rather intrusive
> change..

Right. I don't think that sysfs is the right interface for this problem.
For a short moment I had the idea that you could write an escape sequence
to the tty device, but that would race against the regular output.
An ioctl on the tty device is probably the best you can do here, but
if that's not possible, creating a misc device in order to do ioctl on it
is a rather ugly hack.

 Arnd <><

  reply	other threads:[~2005-03-09 15:40 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-03-08  2:17 [announce 7/7] fbsplash - documentation Michal Januszewski
2005-03-08  3:18 ` Arnd Bergmann
2005-03-08  5:00   ` Matan Peled
2005-03-08 17:39     ` Jesse Barnes
2005-03-08  6:12   ` Jon Smirl
2005-03-08 22:37   ` Michal Januszewski
2005-03-09  0:17     ` Arnd Bergmann
2005-03-09  2:05       ` Michal Januszewski
2005-03-09 15:40         ` Arnd Bergmann [this message]
2005-03-10  0:16           ` Michal Januszewski
2005-03-11 12:27       ` Benjamin Herrenschmidt
2005-03-09 16:54     ` Jon Smirl
2005-03-09 17:29       ` [Linux-fbdev-devel] " Arnd Bergmann
2005-03-09 19:11 ` Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=200503091640.10421.arnd@arndb.de \
    --to=arnd@arndb.de \
    --cc=linux-fbdev-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=spock@gentoo.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).