[Splashy-devel] Splashy-0.1.1 what's missing for official relasing?

[Luis M]

On 5/15/05, Vincenzo Ampolo <vincenzo.ampolo@gmail.com> wrote:
> Hi to all.
> >From 3 days I am playing with splashy and it seems quite stable but...
> There is not the code to see if something goes wrong: if a sh scripts
> fails to load splashy does not go to verbose mode.. why?
> Because splashy now works with a pipe and not with a direct reading from
> vcs1.

Indeed, we need to figure a way to get the errors when they happen.
Reading from the screen is the brute force way of doing it. There
might be a better way. From the top of my head, there might be a way
to get dmesg messages for us and use that. Or a non-invassive way to
send a "verbose" signal to splashy (via fifo perhaps) when this events
happens.
In all cases, we might just need another thread of splashy to handle
these cases.

> To solve this we need to read from the terminal and here can start a
> discussion: what sense does have the pipe? If we always need to read
> from terminal to find error why use a pipe? IMHO using a pipe + a reader
> the used time will increase.

Let's not jump to conclusions as we have not done the research yet.
Going through countless unrelated text messages in memory just to find
specific strings is also very costly, in terms of time taken. So,
that's not the right answer either. (I'm talking about reading the vt
buffer from C and sending signals to splashy. Costly process).

For instance, it would be better, and nicer, if we could simply send a
signal to splashy from initrc's that fail. The big problem is how do
we know it and which initrc's should do that... etc...
We will cross this bridge in the next few days.
=20
> There is also a little bit issue: splashy is stopped one seconds before
> gdm is started and i see screen for one seconds: I'll investigate on
> that.

It appears to be that way but i don't think that's the case. Do this
test and you will see what i mean. First understand this:
Splashy starts before everything else (/etc/rcS.d/S01splashy)
GDM starts before splashy releases the console
X starts as soon as something switches to vt7

To proof that this is correct, do this:
comment out the code in the inirc that switches the vt's (chvt $spl_tty cal=
l).
Then reboot your computer. Now you will see that splashy ends and
stays in tty1. If you log in you will see that gdm is running, and X
is not. And when you manually switch to tty7 (ctrl+alt+f7), then X
starts fine.
That's exactly what chvt $spl_tty does for you. I know that is the
WRONG approach. I told you guys this many times before. We need to
tell libdirectfb that after a certain point on the boot process, any
other process who wants to be the main focus to the tty that splashy
is running in, to let it be. That turned out to be a complicated
problem and I could not get directfb to do this no matter what force
option I set. Also, the manual of directfb explains that using a given
call (can't recall it now: allow-vt-switching?) is experimental stuff;
which meant: it doesn't work. And lo and behold, it doesn't work!
We need to take that issue deeper, if we send an allow-vt-switching to
splashy at 70% or whatever other number before splashyZ stop is
called, and gdm or any other dm is started, then what will happen is
that X and splashy will be both running at the same time in different
tty's. This should be perfectly fine for as long as they share the
/dev/console or whatever they both listen for input. We should dig
deep into the directfb source code, or start playing with the latest
release from upstream, and see what happens.

Hope that's not too confusing and it helps explain this problem to whoever =
asks.



--=20
----)(-----=20
Luis M
System Administrator
Kiskeyix.org=20

"We think basically you watch television to turn your brain off, and
you work on your computer when you want to turn your brain on" --
Steve Jobs in an interview for MacWorld Magazine 2004-Feb

No .doc: http://www.fsf.org/philosophy/no-word-attachments.es.html