On my system, some headers seem to be stuffed in /usr/include/libdrm
and other headers seem to be stuffed in /usr/include/drm .
I think the ultimate upstream goal is for everything to be in
/usr/include/libdrm but my system seems to be in some transition state.
My pkgconfig files only point me to one of the directories, so add some
heuristics to find the other one.
The ask-for-password command has an option
to specify the maximum number of retries to
get the correct password. The default number
of retries was 3. This makes sense for /opt,
and to a lesser degree /home, but it doesn't
make sense at all for /, since failing means
the system won't boot.
The new default is "unlimited". This fixes the
/ case, but has the downside that all integration
code that was depending on the 3 default before
will need to get updated.
If calling a function which is connected to the current object, the object
operated on in the function call is the current object. This is rarely used and
somehow survived without causing crashes despite incorrectly not increasing the
refcount.
When using the old style transition code path where
plymouth quits before X starts, we can't use the drm
renderer for single head nouveau and readeon setups
because their kernel memory manager doesn't allow userspace
write access to the console fb and the old style
transition code needs to dump the last frame of the
plymouth animation to the console fb as intermediate step
of the transition process.
The newer plymouth deactivate mechanism doesn't need the
intermediate console fb copy, so we can stick with the
drm renderer all the time.
This commit conditionalizes the "bail to frame-buffer renderer"
check based on whether the build is configured to enable
the old style transition.
Previously we were connecting to the keyboard but not disconnecting from it as
unset_keyboard was not called before the plugin being destroyed. Now we connect
when on splash start and destroy which makes sure we disconnect before being
destroyed.
Drawing to renderers was resetting the terminal to unbuffered, but this was
also discarding any queued input keys. The fix should keep the input buffer
untouched.
It's possible for activate to be called before map_to_device, for
example if a non-graphical splash plugin is in use. Initialize
map_address to MAP_FAILED so that we won't try to redraw in this
situation.
If the splash hasn't picked up any displays it will abort. We wait for the
possible abort before attaching the keyboard. This is a slight hack as now
add_displays_and_keyboard_to_boot_splash no longer adds the keyboards. Also the
splash plugin can access the keyboard before it is officially opened.
For now it just fixes the terminal fd < 0 assertion bug.
Since the boot splashes handle opening the terminal now,
we need to make sure that we don't try to watch for input on
the terminal until they've opened it.
This should fix some crashes users are reportedly seeing with
the details splash.
A potentially better fix would be to make watch_for_input defer
doing anything on its own using the terminal is opened. That
would require a trigger and some new api to ply-terminal, I think.
Because enter and general keystrokes are handled separately, enter would not
activate the keystroke trigger. Now, you can watch specifically for an enter
press, and enter is accepted as a general any-key trigger.
This means string operations now can be applied on raw strings rather than
having to cast them using the String() class template wrapper.
String("something").CharAt(3)
now becomes simply:
"something".CharAt(3)
When we access to the kernel console's fb, we don't own
it and shouldn't remove it.
This is like commit 808e129fd1,
but for radeon and nouveau instead of intel.
commit cf766763f2 was
messed up in more than one way. The biggest problem
was that It didn't include the Makefile changes needed
to ship the files added to the repository.
This commit fixes that.
This series of commits adds a few configuration files
to replace the kludgey symlink we use now for theme
specification.
In the future, these config files could potentially
be used for other things as well.
