qole | # 231 | 2008-07-21, 22:55 | Report

Hey all,

My research into Xephyr and xorg stuff has led me to xinit, a much more elegant way to start an X-server and window manager. This led me to improve the /usr/bin/xpice script.

Here is my current script, with the tslib and gtk stylus stuff in it as well.

EDIT: improved wmctrl use by getting Window ID first, also added the two WM variables.

Debian /usr/bin/xpice
The first and last lines (export DISPLAY) are probably completely redundant.

---

Last edited by qole; 2008-07-22 at 02:34. Reason: improved wmctrl use, added WM variables

qole | # 232 | 2008-07-21, 23:03 | Report

That has NOT been my experience. Here's a screenshot of Debian matchbox-keyboard running in IceWM on display :1

Benson | # 233 | 2008-07-21, 23:51 | Report

Well, I think that was a case of operator error; somewhere in my chrooting setup I'm stomping on DISPLAY...

But xvkbd is looking quite nice to me (once I figured out it was going to :0 too, and fixed that).


EDIT:

(Attachment from N800 arrived.)

Some of these scripts aren't directly relevant; there's one in there to set the mouse to rightclick for the next five seconds, for example. There's three (matchboxwm and fvmb/mbfv) for switching window managers. I haven't actually ripped your xpice yet anyway, nor installed icewm, as I'm looking at getting (native) fvwm as my principal alternate wm.

Important things are chiefly the debian script, and some stuff in /debian/etc/bootchroot and /debian/root/bin/ for tracking state of chroot vs. boot config files. I'm not sure these are needed though; I think a harmonized config can exist that's the same for booting Debian and Diablo.

I did realize that I left out the config file (/etc/debchroot.conf) that debian now reads; it's reproduced here:In the absence of that file, it carries on with your existing autoconfig for loopback images; if that does exist, however, and defines IMGFILE, it detects whether it's a regular file (loopback image) or block special file (boot partition) and mounts accordingly. I also fixed a bug or two (ext3 wasn't loading all modules, for one), and made a couple tweaks here and there. There's more work that can be done, clearly, but I think it's decently tidy now.

If you like it as it stands, and don't feel too strongly about particular indentation styles, I'd kind of like to reformat it and resubmit that (after I finish making a couple more functional changes...). I find the indentation style you were using difficult to follow, but I stuck with it for easy merging of changes. If you prefer what you were doing, that's fine too.

Attached Files

scriptage.tar (27.0 KB, 162 views)

---

Last edited by Benson; 2008-07-22 at 00:08.

qole | # 234 | 2008-07-22, 03:03 | Report

I have been having some serious problems with xvkbd crashing due to focus problems in IceWM.

See my post above for the full xpice script. I think it is working very well now.

...What do you think about making the config file a user-editable file in the /home/user folder? (/home/user/.chroot maybe?)

Please see above for my disclaimers about lack of formal CS education. Indent as you please, but, also, please comment fully.

I will wait for your version 2 (reformatted).

I will be away from the Internet for two or three days, starting tomorrow...

Benson | # 235 | 2008-07-22, 16:09 | Report

OK, for the benefit of anyone else reading (and curious what script changes will show up in Bundyo-Build), and even the Qole himself, should he inadvertently stumble into a lost pocket of civilization with a convergently-evolved wifi standard. (And also to remind me what I said I'd do... )

chroot
All scripts will be reformatted (indentation styles are one of the classic flamewar causes, so I'll take the liberty to proclaim they'll be reformatted properly!).

It'll also include an updated version of xpice, again reformatted.
I'll try to ensure they are well commented throughout, though that's never been my strong point.

Config will be in /home/use/.chroot, and will (likely) involve options for xpice, as well. Maybe (up to Qole) xpice will be renamed something else, and be easily changeable for different window managers; even if so, default behavior (in the absence of a config file, or with the shipped config file, if any) will be the same.

FVWM/multi-Xomap
Separately, and if Darken doesn't beat me to it, I may be releasing an independent script-up for running a second N+1th Xomap on a second N+1th VC, and using native FVWM (with an N800-friendly config) on it. (If Darken beats me with the release, I'll just sit back and gripe about his... )

This is a separate project with no chroot required, more like PB's KDE, but much less ambitious. It does provide a dandy place to run some chroot apps, though, hence its mention here.

FVWM, BTW, also has a set of impressive capabilities for small-screen work; any window may be scrollbarred by the WM, for instance, and you can set up virtual desktops larger than the screen, as well as normal independent desktops. I haven't been using IceWM, so I don't know how much it can do, but I suspect with a proper config FVWM2 will be better for most power users.

Other benefits, while I'm bragging, include full-screen resolution (rather than windowed) (EDIT: Guess I'm wrong here; Xephyr is running fullscreen in Qole's screenshot above.) and somewhat improved efficiency from direct-to-FB rendering (although that shouldn't be much different) and finally no impact from matchbox/hildon grabbing keys, popping notifications up, etc...

---

Last edited by Benson; 2008-07-22 at 16:19.

geneven | # 236 | 2008-07-23, 09:06 | Report

I'm not particularly up to this techie thread, but I do want to put my vote in for Fluxbox as an alternate window manager -- it seems to be popular, and I have reluctantly started abandoning Window Maker in favor of Fluxbox. What I love about Window Maker is the ease of docking applications -- you can basically just move an application over to the dock, and that's that, permanently.

But Fluxbox has a "slit" that is not quite as easy, but is usable -- and it takes up less screen real estate, which would be important on a tablet. There are of course a lot of different "boxes", but I don't have much experience with them. I see that "openbox" actually exists among my installable applications, but I don't know how to use it. I use Fluxbox with an application called wmdrawer, which I learned about in Window Maker, but it's even more useful in Fluxbox. You click it and, accordian-like, a menu of programs scoots out for you to select from. This and things like auto-hide would be great on a tablet, it seems. Unfortunately, from some points of view, setting up Fluxbox properly is a very command-line intensive sort of operation, until you set it up to avoid that. But it is fast, flexible, and frugal with system resources, which is the key to its popularity.

Stskeeps | # 237 | 2008-07-23, 09:23 | Report

Well, there's one thing I've been wondering about, - The Debian chroot project(s) and patches have same problems as the bootable Debian for tablets - that we distribute around big tar.gzs (which we don't do anymore) and such and add patches manually and stuff.

If any of you are interested in using my installer (which allows partioning, mkfs, debootstraps and installs packages on top) from http://trac.tspre.org/projects/nit-debian and maybe have a joint project regarding Debian on tablets (both boot and chroot).

Since we would probably share many of the same user interface packages to get things working under Xomap/on the tablet etc, I'd be more than interested to create support in installer for a chroot install.

I also have packages generating specific environments, and installer supporting installation goals so people could have nit-env-fluxbox, nit-env-xfce4, or, nit-env-theirown.

If any interest exists for this, I'm always up for discussion in private messages here (or on this thread), or on #maemo on IRC

The installer is already quite configurable and the base package system is quite easy to work with, so it would be possible to have different configs for chroot Debian and bootable Debians.

Benson | # 238 | 2008-07-23, 16:17 | Report

EDIT: Note: I've only skimmed your project's SVN, so I could be understanding some of it wrong...

To me, that's the way this ought to be installed, long-term; the installation/filesystem image side, though, belongs to the vacationing Qole. While I'm reluctant to speak for him (and even more reluctant to search his old posts ), I think he's expressed interest in going with your install system. I'm not sure if a merge before the upcoming release is feasible timewise, so we'll definitely have to wait to hear on that. I'm optimistic, though.

Sounds good. I'll have scripts ready for Qole by tomorrow, and those scripts are most of the Maemo-side stuff. Seems like that can be packaged up as a .deb, which gets installed through your installer.

For now, at least, this thread's the natural place, so Qole can catch up after his return.

That's one thing I hope we can avoid; I think it's possible to align the systems sufficiently that the same install works for both chroot and boot purposes.

So far (in my understanding; I've not actually used Qole's image yet), the only thing that needs to be done (on the Debian side) is to add one package depending on Xephyr and containing an improved xpice-like system for starting the X server in the correct window; probably using Xsession, instead of hardcoding one WM. (Technically, that's not even a fundamental requirement, as we're capable of running multiple Xomap instances, or even running chroot apps in :0, with matchbox...)

That doesn't interfere with anything for booting. The only conflicts I've seen are /etc/passwd stuff, which can be harmonized by keeping the same username/UID pairs in both systems. Do you know of other issues that would force boot and chroot to be separate?

I'd hope we can get it just to one extra package to be installed Maemo side, which provides generic chroot-to-debian capability, and optional packages on each side to provide some sort of X server + WM capability...

fatalsaint | # 239 | 2008-07-23, 16:30 | Report

I have the current bootable Debian working fine under qole's script after apt-get install xserver-xephyr wmctrl .. modified his latest debian script since it wants to use his image file and not directory path.. but it all runs fine and I have IceWM launching using the C compiled host2win app here.

Seems to work just fine... I don't copy over the passwd/group files, and I don't mount over my user directory.. I'm not sure why Qole did.. the user account UID/GID seem the same on both so permissions should be fine.. but the mpd user and the /home/user/music folder is required by the mpd app.. so if I leave them alone I have experienced no issues.. and even started mpd in IceWM chrooted and listened to music beautifully...

I prefer it this way to Qole's image because I can opt to boot to it if I want.. or for when I don't want to put up with my wireless problems I just boot into Diablo and Chroot in.. Absolutely love it.

ETA: Hah.. I had my device in Offline Mode in Maemo chrooted to IceWM.. went to maemo and /etc/init.d/btcond stop, and in IceWM /etc/init.d/bluetooth restart .. and I got bluetooth switched from maemo to the debian side lol. Not extremely useful.. but still cool; have bluetooth in offline mode with wireless still totally disabled. (course any battery saved would be killed by the chroot environment.. hah.)

---

Last edited by fatalsaint; 2008-07-23 at 16:37.

Stskeeps | # 240 | 2008-07-23, 17:44 | Report

After reading through 24 pages of Debian chroot posts.., just a summary and some questions / various coherent and incoherent stuff

"In-maemo" packages/editings:

* 'Debbie script'/Hilda etc that executes command in chroot (and mounts if needed), no X session needed, and views in maemo Xserver
* Methods for starting full debian X session, like /etc/init.d/chroot-start-xephyr-xsession is a way to do

* Application .desktop files that runs the debbie/chroot script for easy access, using matchbox as WM (maemo's)
* Maybe matchbox movable windows hack & sudo tricks

- My installer can download and dpkg -i stuff that's needed to support this through easy configuration

Ways of storing installation image:
* ext2/ext3 image files
* tar zxf onto a partition (johnx's beta3)

I'm personally not fond of image files but I guess they're good enough when there's no partitioner (which we do have in NIT-Debian).
Or for scenarios where we have a "easy debian" deb (that would bootstrap the system and set default settings?) - but I haven't seen "bootable" ext2/3 images?

X-server possibilities:

Straight to OS2008 X display.. (chroot run)
Xephyr (ability to have in a Maemo WM window, both fullscreen and not?)
VNC method (slow..?)
Xserver-omap on another virtual console (enabling switch between Maemo and Debian in both user interfaces through chvt?)
- does this have performance penalty?
- advantages of this would be similar scripts for boot and chroot for starting X session? (see http://trac.tspre.org/projects/nit-d...it.d/x-session).
- I do all the GTKSTYLUS etc tricks in Xsession instead, but I guess that also means that the goal is a X session, not just a debian app with target on Maemo X display..


Maemo-Debian interaction, /etc/group, /etc/users..:

Just viewing differences of those between maemo and my setup..
for the sake of the tablet-user (which i have a package creating), there's nothing saying that we can't have the useradd command
set a specific UID/GID (29999/29999) for the user when adding. Is there any other technical reason why they should be shared?

DBUS communication? What issues are there with communicating with in-Maemo hald/dbus from Debian?

Maemo-Debian UI interaction - scripts that "make life easier" when in chroot such as switch back to OS2008, etc.
I guess it would be possible to detect if we booted or we chrooted, either through environment variables or other things,
so we could have a package adding different tricks for UI interaction with Maemo, that just doesn't
initialize in booted Debian (and maybe some that doesnt activate in chrooted Debian either).

Besides some of the observations given in this, I see no reason whatsoever that chroot and boot version can't be two sides of the same thing
- and maybe even that the installer sets up chroot initially but user can also choose to dual-boot and boot into the same Debian session.


In any case, it could be interesting to combine the creativity of the chroot people and the booting people to give a better user experience, instead
of two groups working on exact same thing..