New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Localize splash messages #641

Open
anaconda opened this Issue Oct 21, 2014 · 3 comments

Comments

Projects
None yet
2 participants
@ghost
Contributor

ghost commented Oct 21, 2014

Ideally based on the locale set in XBMC.
This is just a reminder. I'll be working on it once #624 (comment) is fixed.

@ghost ghost assigned anaconda Oct 21, 2014

@anaconda anaconda added this to the XBian 1.0 (Final) milestone Oct 21, 2014

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Oct 22, 2014

Contributor

@mk01 can you please push the current xbian-package-splash.

I've modified my local /usr/bin/splash (shell script), but on Git (xbian-package-splash) it's a binary.

Contributor

ghost commented Oct 22, 2014

@mk01 can you please push the current xbian-package-splash.

I've modified my local /usr/bin/splash (shell script), but on Git (xbian-package-splash) it's a binary.

@mk01

This comment has been minimized.

Show comment
Hide comment
@mk01

mk01 Dec 16, 2014

Member

@anaconda

recreated xbian-package-splash as $xbiangit repository.
upstream source is CurlyMoo's splash V2 but with lot of changes. some I pushed back to curly some other not - after code cleanup should be sent most of them again back CurlyMoo.

  • 16/32 bit FB support was pushed
  • FB mapped memory is on --black freed and reinitialised on returning from --black. the new splash could (on 32bit FB) with new z-axis take as much as 35MB from RAM. when freed, the actual usage can drop to ~300kb
  • on return from --blank active console is returned to its previous parameters (that means if XBMC changed it after start) - e.g. Cubox-i boots to 1920x1080, xbmc is set to run with 1280x720. console is also un-blanked including other "resets" needed for it to work (after xbmc's crash for instance)
  • with the new FB code on RPI the process wasn't able to write to FB after XBMC quit. imx6 was fine, RPI only after complete FB con reset. never found the specific problem. code was all processed correctly, memory mapped to FB, but changes never got it to screen which only stayed BLACK.
  • maybe others I don't remember

two important points: old splash was using mmapped file for communication between daemon and client (or accepting control commands from client instance). this added need for extra handling of NS change during rootfs move (initramfs -> root) - daemon has to be signalled about NS change with its auto restart under new root.

plan was to use sockets instead of mmap with new version - curlymoo finally changed to net socks - probably to avoid the extra code on NS change. this saved few lines of code but created new 'stupid' problem. daemon can't be used without configured network (at least lo interface started and configured).
this can be "fixed" by early lo configuration, but there are more consequences - like for instance halt and reboot init targets (simply old sysv and all the scripts and support tools) never expected network running until kernel goes stop.

also by change to threaded net socks, daemon can receive n- incoming connections but proper locking is missing (so crashes or daemon on shutdown but another client trying to configure FB), client commands out of order etc etc.

also the client commands have not been compatible between old and new splash (but XBian has quite many references to splash from various places or packages).

it would be nice to adapt Splash sources accordingly but it would mean something like mini-project. so network scripting was moved to upstart ahead of Debian/Wheezy, completely removed from sysv. lo interface is started in early initramfs to have splash before having /. lo interface is also excluded from net deconfiguring jobs.

for diff parameters problem and locking(and in order processing of client requests) there is wrapper script providing the old splash like interface (in the old target /usr/bin/splash). it is also handling starting and stopping the daemon itself (previous splash had just one binary which forked if it wasn't running yet).

it is running without issues for months now but for future reference - keep this info because it will come the day nobody will remember WHY and more important HOW. ;)

the mem buffer free on --blank should go back CurlyMoo, the special handling on --blank return I'm not so sure - mostly because can change with every update to EGL imx6 xbmc implementation. Also the FB ioctl calls doesn't behave the same way on RPI/imx6 in corner cases and it took me lot of time to elaborate fb_init() and fb_unblank(restore) calls order / combination to get same result. that means better not touch if absolutely needed.

repo is pushed now, actual sources on build server in 'working'. what is needed is to add install target to Makefile (to have standard $xbiangit scripts working). actual deb structure is in content-tpl as usual, I only removed binaries (replaced them with .placeholder for reference only until Makefile is patched).

can you please finish it up? also the fb.c code would NEED some cleanup (reformatting and space/tab consolidation).

Member

mk01 commented Dec 16, 2014

@anaconda

recreated xbian-package-splash as $xbiangit repository.
upstream source is CurlyMoo's splash V2 but with lot of changes. some I pushed back to curly some other not - after code cleanup should be sent most of them again back CurlyMoo.

  • 16/32 bit FB support was pushed
  • FB mapped memory is on --black freed and reinitialised on returning from --black. the new splash could (on 32bit FB) with new z-axis take as much as 35MB from RAM. when freed, the actual usage can drop to ~300kb
  • on return from --blank active console is returned to its previous parameters (that means if XBMC changed it after start) - e.g. Cubox-i boots to 1920x1080, xbmc is set to run with 1280x720. console is also un-blanked including other "resets" needed for it to work (after xbmc's crash for instance)
  • with the new FB code on RPI the process wasn't able to write to FB after XBMC quit. imx6 was fine, RPI only after complete FB con reset. never found the specific problem. code was all processed correctly, memory mapped to FB, but changes never got it to screen which only stayed BLACK.
  • maybe others I don't remember

two important points: old splash was using mmapped file for communication between daemon and client (or accepting control commands from client instance). this added need for extra handling of NS change during rootfs move (initramfs -> root) - daemon has to be signalled about NS change with its auto restart under new root.

plan was to use sockets instead of mmap with new version - curlymoo finally changed to net socks - probably to avoid the extra code on NS change. this saved few lines of code but created new 'stupid' problem. daemon can't be used without configured network (at least lo interface started and configured).
this can be "fixed" by early lo configuration, but there are more consequences - like for instance halt and reboot init targets (simply old sysv and all the scripts and support tools) never expected network running until kernel goes stop.

also by change to threaded net socks, daemon can receive n- incoming connections but proper locking is missing (so crashes or daemon on shutdown but another client trying to configure FB), client commands out of order etc etc.

also the client commands have not been compatible between old and new splash (but XBian has quite many references to splash from various places or packages).

it would be nice to adapt Splash sources accordingly but it would mean something like mini-project. so network scripting was moved to upstart ahead of Debian/Wheezy, completely removed from sysv. lo interface is started in early initramfs to have splash before having /. lo interface is also excluded from net deconfiguring jobs.

for diff parameters problem and locking(and in order processing of client requests) there is wrapper script providing the old splash like interface (in the old target /usr/bin/splash). it is also handling starting and stopping the daemon itself (previous splash had just one binary which forked if it wasn't running yet).

it is running without issues for months now but for future reference - keep this info because it will come the day nobody will remember WHY and more important HOW. ;)

the mem buffer free on --blank should go back CurlyMoo, the special handling on --blank return I'm not so sure - mostly because can change with every update to EGL imx6 xbmc implementation. Also the FB ioctl calls doesn't behave the same way on RPI/imx6 in corner cases and it took me lot of time to elaborate fb_init() and fb_unblank(restore) calls order / combination to get same result. that means better not touch if absolutely needed.

repo is pushed now, actual sources on build server in 'working'. what is needed is to add install target to Makefile (to have standard $xbiangit scripts working). actual deb structure is in content-tpl as usual, I only removed binaries (replaced them with .placeholder for reference only until Makefile is patched).

can you please finish it up? also the fb.c code would NEED some cleanup (reformatting and space/tab consolidation).

@mk01

This comment has been minimized.

Show comment
Hide comment
@mk01

mk01 Dec 16, 2014

Member

last info, there is only "rpi" platform config - also it is compiled against wheezy (raspbian) root. but AS compiled - the same .deb is used for cubox too. the base libs (libm, libjpeg, libfreetype and libz) match. arm is compiled as HF.

Member

mk01 commented Dec 16, 2014

last info, there is only "rpi" platform config - also it is compiled against wheezy (raspbian) root. but AS compiled - the same .deb is used for cubox too. the base libs (libm, libjpeg, libfreetype and libz) match. arm is compiled as HF.

@ghost ghost unassigned anaconda Jun 8, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment