Re: [E-devel] E SVN: raster IN trunk/exquisite: . src/bin

[Lucas De M. <luc...@pr...>]

On Fri, Mar 23, 2012 at 9:59 PM, Carsten Haitzler <ra...@ra...> wrote:
> On Fri, 23 Mar 2012 15:40:10 -0300 Lucas De Marchi
> <luc...@pr...> said:
>
>> On Fri, Mar 23, 2012 at 2:23 AM, Enlightenment SVN
>> <no-...@en...> wrote:
>> > Log:
>> > add -cleanvt
>> >
>> >
>> >
>> > Author:       raster
>> > Date:         2012-03-22 22:23:44 -0700 (Thu, 22 Mar 2012)
>> > New Revision: 69575
>> > Trac:         http://trac.enlightenment.org/e/changeset/69575
>> >
>> > Modified:
>> >  trunk/exquisite/ChangeLog trunk/exquisite/src/bin/main.c
>> >
>> > Modified: trunk/exquisite/ChangeLog
>> > ===================================================================
>> > --- trunk/exquisite/ChangeLog   2012-03-23 03:46:36 UTC (rev 69574)
>> > +++ trunk/exquisite/ChangeLog   2012-03-23 05:23:44 UTC (rev 69575)
>> > @@ -0,0 +1,10 @@
>> > +2012-02-10  Carsten Haitzler (The Rasterman)
>> > +
>> > +        1.0.0 release
>> > +
>> > +2012-03-23  Carsten Haitzler (The Rasterman)
>> > +
>> > +        * add -cleanvt to enable clean "fade out" animation before giving
>> > +        up the VT.
>>
>> IMO it's much better to tell X to run on the same VT (i.e. the first
>> one), start X with "background none" and use the same background. Then
>> you have a flicker free boot and user has the feeling that boot was
>> much faster then it really was.
>
> x will not be able to own that vt because exquisite already owns it. also

That's why you still ask it to "exit gracefully"... that means: keep
it in gfx mode. X with no background, in the same VT, will just use
the last image left by the splash (given your gfx driver supports
that).

> remember that the driver will most likely reconfigure the gfx chip - possibly

I'm talking about drivers with KMS (intel here). It sure doesn't work
with proprietary nvidia driver since it doesn't support kernel mode
setting.

> with a different resolution (this definitely happens on  nvidia drivers in many
> cases as the kernels vesa support often can't detect the correct resolution).

If you have a driver with KMS, don't worry about that.

> i'm actually using fifos mostly to cut down the overhead of writing status
> updates as it needs much simpler tools. :)

It's almost the same work to support abstract sockets.... but it's ok,
it was already written.

>
>> "2. You need a /tmp directory for the UNIX socket that is used to talk to
>> exquisite. The exquisite-write utility sends messages to exquisite via a UNIX
>> domain socket created in /tmp. This needs to be writable for exquisite to
>> start."
>>
>> This implies that you need to have /tmp mounted or a writable / early
>> on boot sequence. If you use abstract sockets you can start exquisite
>> earlier. With dietsplash I use this and run the run the splash even
>> before handing off to the init process.
>
> exqusitie needs a lot of infra - eina, ecore, evas, edje, an edje file, embryo
> etc. etc. to get up and running. these in turn need modules. using /tmp isn't a
> tall order :) also i think i wrote this before abstract socket support was in

If you want your splash to appear asap, you better start it early.
Supposing we are using KMS, that means:

1. bootloader set up gfx and put an img as background
2. kernel comes up, see the gfx is in the right setup and doesn't touch it
3. splash comes up, start animations and give control to init
4. We are about to execute X: ask bootsplash to exit nicely
5. X comes up and use what the bootsplash left

The hardest part is (1). The others can be done for drivers that have
KMS, then you have a flicker-free boot.

> ecore_con or very early after it was added. i did it then never touched it
> again as it worked.

Ok. We could remove that limitation: using abstract sockets is veeery
simple, no need to support that in ecore_con (example of a client
using it: http://git.profusion.mobi/cgit.cgi/dietsplash.git/tree/src/dietsplashctl.c)


Lucas De Marchi