[08:47] <kvarley> The Google Samsung Chromebook has the same ARM chip in as the Nexus 10 - does that mean that I should technically be able to run the ARM versions of Ubuntu on the tablet?
[08:51] <Tm_T> kvarley: yes, doesn't mean it would have all the pheripherals functioning correctly though
[08:52] <Tm_T> pheripherals including but not limited to: display drivers (;
[08:52] <kvarley> Tm_T: Hmm, true. Could I boot the 13.04 image with the android kernel though?
[08:52] <kvarley> Tm_T: A patched driver has hit the 13.04 repos
[08:53] <Tm_T> kvarley: I suppose it would be worth trying, but I have no knowledge about the said chromebook
[08:53] <kvarley> Or so Phoronix claims http://www.phoronix.com/scan.php?page=news_item&px=MTI5Mzg "The Ubuntu 13.04 repository just received ARM's new universal X.Org graphics driver,  a.k.a. the xf86-video-armsoc DDX. This is a generic ARM SoC DDX driver  for the X.Org Server originally derived from the xf86-video-omap driver."
[08:54] <kvarley> Tm_T: I may have to read up on this. I think the stumbling block is having to include the video driver in the rootfs because I'll likely have no wifi access on the device
[08:55] <kvarley> Hmm, the SoC is the same but the GPU is different
[08:58] <bmw> Hello. Can you help me remap arrow keys + Alt to End,PgUp etc... I think xmodmap can't help.
[09:02] <bmw> On Chromebook (:
[09:33] <hrw> kvarley: 13.04 has most of things you need to get ubuntu running on chromebook
[09:38] <kvarley> hrw: Out of the box?
[09:38] <hrw> kvarley: define 'out of box'
[09:38] <kvarley> hrw: fresh install
[09:38] <hrw> define 'fresh install'
[09:38] <kvarley> hrw: lol, as in the images published for the chromebook 13.04
[09:38] <hrw> there will be no images for chromebook
[09:38] <ogra_> no, there are no images
[09:39] <ogra_> i wouldnt say "will be" ...
[09:39] <ogra_> but currently there arent any
[09:39] <hrw> no one wanted to join in development of chromebook support and I am too lazy/occupied to work on it
[09:39] <ogra_> i use my CB to much, else i would probably invest some time to make images
[09:40] <ogra_> but creating the first set simply means a lot of reinstalls
[09:40] <kvarley> hrw: Ok, if I took this image raring-preinstalled-desktop-armhf+ac100.tar.gz would it at least boot on the Nexus 10 if I booted with the Android kernel?
[09:40] <hrw> kvarley: nexus 10 != arm chromebook
[09:41] <kvarley> hrw: I know, but they share the same SoC so the configuration would likely be similar
[09:41] <hrw> kvarley: ac100 share the same SoC as "LG 4xHD" cellphone - would ubuntu run on a phone?
[09:42] <hrw> kvarley: for nexus10 you may ask ubuntu touch guys do they have some image
[09:43] <kvarley> hrw: ok, thanks
[09:43] <ogra_> for nexus 4,7,10 and galaxy nexus there are touch images
[09:43] <hrw> kvarley: if you use ac100 image and boot it with default chromeos kernel it will start
[09:44] <hrw> no x11 probably but will start
[09:44] <ogra_> it might even fall back to xfbdev ... who knows :)
[09:49] <hrw> anyway that reminds me that 3.4.0-7 is waiting for be built/uploaded
[09:51] <hrw> and I finally got microsd->sd adapters which do not stick out from chromebook
[09:52] <hrw> ogra_: http://dx.com/p/2-in-1-tf-card-to-sd-card-adapter-usb-card-reader-white-126299
[09:53] <hrw> ogra_: cut usb part and it will not stick out
[09:54]  * ogra_ wonders why the CSS is so messed up 
[09:54] <ogra_> its unreadable here ... layers of text over layers of text
[10:08] <hrw> git-buildpackage + chromium-kernel git repo == problems ;d
[10:13] <hrw> good thing is that aptitude works now on armhf
[10:15] <ogra_> pfft, aptitude ...
[10:15]  * ogra_ doesnt know anyone using it 
[10:16] <ogra_> pretty pointless to have two package DBs installed just for some commandline UI
[10:16] <hrw> ogra_: flash-kernel still does not have DT support?
[10:17] <ogra_> i didnt add any ... and nobody sent patches
[10:17] <ogra_> ask ppisati :)
[10:17] <hrw> ogra_: show me other useful APT UI for console and I may switch
[10:17] <ogra_> aptitude is *not* an apt UI ... it has nothihng to do with apt at all
[10:18] <hrw> I use it as such ok?
[10:18] <ogra_> it is its own package tool ... simply duplicating what apt does
[10:18] <ogra_> just wastes extra disk space with an additional DB
[10:19]  * ogra_ stays with apt :)
[10:20] <hrw> I went dselect -> console-apt -> aptitude
[10:20] <ogra_> well, except the gui part aptitude today has no features that apt doesnt provide also
[10:21] <ogra_> (it used to in the past)
[10:21] <hrw> sure, but I use that UI part
[10:21] <ogra_> yeah
[10:22] <ogra_> i have better usage for teh several MB that wastes on my disk :)
[10:22] <hrw> ;D
[10:29] <hrw> hm. hacking flash-kernel does not have sense
[10:29] <hrw> it can guess where rootfs is from /proc/cmdline but can not where kernel is stored
[10:30] <ogra_> in /boot indeed :)
[10:30] <ogra_> along with the dtb
[10:30] <hrw> ogra_: will you package u-boot for chainloading?
[10:30] <ogra_> i pull whatever linaro packages ... as usual
[10:31] <hrw> Linaro does not do any chromebook stuff
[10:31] <ogra_> if i even have to pull ... i think jcrigby can just upload nowadays
[10:31] <ogra_> linatro has the mainline branch as base for their packages ... so you could ask for a binary that goes into ubuntu i guess
[10:32] <hrw> I have no idea which ver of u-boot works for chainloading
[10:33]  * ogra_ neither
[10:33] <Rjs> I use aptitude all the time, largely because of the UI - it is much easier to select packages from multiple choices or look at suggests and recommends manually using an interactive UI than trying to add things to the apt-get command line iteratively
[10:33] <Rjs> though mainly on debian, and especially on minimal single-use embedded systems (instead of a desktop), so I guess the situation may look different from an Ubuntu desktop perspective...
[10:34] <hrw> Rjs: I doubt that ubuntu desktop comes with something similarly usable
[10:36] <ogra_> well, especially on embedded i wouldnt use aptitude ... unless you have a lot of diskspace
[10:37] <hrw> yep
[10:37] <hrw> there are other tools to get rid of useless stuff
[10:37] <hrw> debfoster for example
[10:37] <Rjs> ogra_: hmm, on embedded I've found that aptitude is the best way (for me) to keep the number of installed packages minimal and still have all features I need (I use it with auto-install recommends off and select manually perhaps around 70% of the recommends)
[10:38] <hrw> Rjs: what is your 'embedded' hardware?
[10:38] <ogra_> i'm not talking about comfort :)
[10:38] <ogra_> aptitude adds its own package database
[10:38] <ogra_> in parallel to the apt one
[10:38] <Rjs> hrw: mostly alix's embedded geode pc's (i.e. x86) and a few openmoko gta02's
[10:39] <hrw> Rjs: alix was nice hw. I used 1c for few years
[10:39] <ogra_> ogra@chromebook:~$ du -hcs /var/lib/apt/lists/
[10:39] <ogra_> 95M	/var/lib/apt/lists/
[10:39] <Rjs> if plain apt had an interactive UI with the features of aptitude, I'd probably switch to it, but I haven't found anything comparable...
[10:39] <hrw> hrw@krolik:/var/lib$ du -hs aptitude/ apt
[10:39] <hrw> 7,8M    aptitude/
[10:39] <hrw> 84M     apt
[10:39] <ogra_> it wont actually double that up but will definitely add a lot on top
[10:40] <hrw> -rw-r--r--  1 root root 4046282 kwi  4 12:14 pkgstates
[10:40] <hrw> -rw-r--r--  1 root root 4046326 kwi  4 12:13 pkgstates.old
[10:40] <hrw> that's all?
[10:40] <ogra_> dunno, as i said, never using aptitude
[10:41] <Rjs> I've found on my system that keeping auto-install recommends on (which I guess would be the only practical choice with a non-interactive UI) would add much more than that amount of diskspace, plus lots of services and background processes that I have no use for
[10:41] <ogra_> so switch it off :)
[10:42] <Rjs> but it's probably heavily dependent on the user preferences and what the systems are for (e.g., I have several desktop systems without gvfs or udisks or network-manager or all that complexity, but still a somewhat minimal and very usable X11 system for my purposes)
[10:42] <ogra_> pfft, X11 .... Mir is the future
[10:42] <ogra_> *g*
[10:43] <ogra_> at least on arm
[10:43] <Rjs> but not the present :)
[10:43] <ogra_> well, i heard it works on nexus 4 and 7 already
[10:44] <ogra_> the advantage is that it doesnt need any special drivers ... you can just use the android blobs
[10:44] <hrw> ogra_: http://paste.ubuntu.com/5676209/ - everything needed for device tree support?
[10:45] <ogra_> hrw, dunno, as i said, talk to ppisati
[10:45] <hrw> ppisati: ping  ^^
[10:46]  * ogra_ has no clue at all how dtb stuff is implemented in our kernels
[10:46] <hrw> ogra_: s/dtb/DT/
[10:47] <ogra_> and given that nearly all future ubuntu arm development will be android kernel based ....
[10:47] <ogra_> (except for  server i guess)
[10:48] <hrw> ogra_: I heard rumours that s/eglibc/bionic/ is also planned
[10:49] <ogra_> hrw, nope
[10:49] <ogra_> that would have been an april fool :)
[10:50] <hrw> ogra_: there was such? :D
[10:50] <ogra_> we do make heavy use of libhybris to bridge between the two
[10:50] <hrw> I was mostly travelling on 1st April
[10:50] <hrw> Saarbrücken -> FRA -> TXL -> home
[10:51] <ogra_> yeah
[10:51] <ogra_> i read g+ :)
[10:53] <ppisati> hrw: dtb support for flash-kernel i suppose?
[10:53] <hrw> ppisati: yes
[10:53] <hrw> ppisati: just other way to identify machine
[10:54] <ppisati> hrw: iirc we had another patch for dtb support from... marvin?
[10:54] <ppisati> marvin24: ^
[10:55] <ogra_> it was similar iirc
[10:55] <hrw> 19:24 < marvin24> hi, I'm about to add http://paste.ubuntu.com/5602702/ to our version of flash-kernel
[10:55]  * ogra_ remebers it at least using the same path in /proc
[10:55] <hrw> that's not that
[10:56] <hrw> https://launchpadlibrarian.net/133791292/flash-kernel_3.0~rc.4ubuntu29_3.0~rc.4ubuntu29-tegra.diff.gz
[10:56] <hrw> also not that
[10:56] <hrw> he just added support for BT based Tegra board using FDT entry from /proc/cpuinfo
[10:57] <hrw> ~hail /lastlog marvin
[11:38] <hrw> ech, 3.4.0-6 has broken keyboard
[12:13] <marvin24> hrw: what is BT based?
[12:13] <hrw> marvin24: DT? Google Snow (aka Samsung ARM Chromebook)
[12:13] <marvin24> ppisati, hrw: my goal is to find a way to tell uboot which DT to load until we have full DT support in uboot
[12:14] <marvin24> hrw: no, this is for ac100, but all tegra2/3/4 boards should be supported
[12:14] <marvin24> btw, does the flash-kernel db support wildcards?
[12:14] <marvin24> e.g. Machine: nVidia Tegra* (Flattened Device Tree)
[12:15] <hrw> marvin24: your change used name from /proc/cpuinfo while mine adds reading of model from DT
[12:15] <marvin24> hrw: no, I use /proc/device-tree/model as you
[12:15] <marvin24> you posted the link
[12:16] <marvin24> https://launchpadlibrarian.net/133791292/flash-kernel_3.0~rc.4ubuntu29_3.0~rc.4ubuntu29-tegra.diff.gz
[12:16] <marvin24> this is used to copy the device tree to /boot where uboot can find it
[12:16] <hrw> marvin24: you use /proc/device-tree/model to copy DTB but not to identify device in flash-kernel
[12:16] <marvin24> hrw: sorry, but why is this necessary?
[12:17] <marvin24> the kernel supports multi-soc
[12:17] <hrw> marvin24: Chromebook returns "SAMSUNG EXYNOS5 (Flattened Device Tree)" which covers also Andale which can not boot Chromebook kernel
[12:17] <hrw> marvin24: I have only 3.4 kernel for Chromebook
[12:18] <marvin24> looks more like missing Andale kernel support for me - right?
[12:18] <hrw> marvin24: so my goal is to use DT model when cpuinfo reports DT device. this way same SoC devices may run other flavours
[12:18] <hrw> marvin24: I want to support *one* device as I do that in my free time
[12:18] <marvin24> I also check for "grep -q 'Flattened Device Tree' /proc/cpuinfo " fiest
[12:18] <hrw> when Linaro kernel teams will get Andale into working condition then they will have 3.9-rc etc
[12:18] <marvin24> *first
[12:19] <hrw> marvin24: moment...
[12:19] <marvin24> hrw: are you also planing to copy the device tree to /boot ?
[12:19] <marvin24> or just use the device tree from uboot
[12:20] <marvin24> I don't know how far exynos support has grown
[12:21] <hrw> when user runs 'flash-kernel' script it checks /proc/cpuinfo for Hardware line and then do whatever it has to. For your Tegra work it is enough as you have one kernel for all devices + set of DTB files. So flash-kernel do what it has to and then kernel postinst runs your script to put proper DTB in /boot/ according to /proc/device-tree/model file. In my case on Exynos5 we do not have that luxury and different devices (so far) use different kernels so I need to hav
[12:22] <hrw> and Chrombook is using signed kernels...
[12:24] <hrw> marvin24: but I see how my patch may make your work harder
[12:27] <marvin24> hrw: thanks for the explaination
[12:27] <hrw> http://paste.ubuntu.com/5676446/ may be better as allows to cover your usecase (one database entry for whole DT platform) and mine (many database entries per DT platform)
[12:28] <hrw> will require some comments in code to describe it
[12:29] <marvin24> hrw: I don't see why your original patch should cause problems
[12:30] <hrw> marvin24: your entry from https://launchpadlibrarian.net/133791292/flash-kernel_3.0~rc.4ubuntu29_3.0~rc.4ubuntu29-tegra.diff.gz will be skipped as DT model name would be used
[12:30] <hrw> marvin24: http://paste.ubuntu.com/5676446/ checks /proc/cpuinfo, gets "NVidia Tegra DT" identifier. Checks database - o, we support it already - go.
[12:31] <hrw> marvin24: when there is no "This platform DT" in database it will read DT model name and search for it.
[12:31] <marvin24> ah, machine is something like Toshiba AC100 again instead of common "Tegra20 ..."
[12:31] <hrw> yes
[12:32] <marvin24> hrw: ok, so your latter patch should match the common device tree early
[12:32] <hrw> yes, if it is in flash-kernel database
[12:33] <marvin24> now I got it - thanks!
[12:34] <hrw> marvin24, ppisati: http://paste.ubuntu.com/5676460/ - is this comment readable enough?
[12:36] <marvin24> hrw: looks good to me
[12:36] <hrw> cool
[12:37] <marvin24> now how can I get the db entry into offical flash-kernel?
[12:37] <hrw> marvin24: report a bug
[12:37] <hrw> with debdiff
[12:38] <marvin24> ok, thanks again
[12:38] <hrw> marvin24: so on AC100 what is in /proc/device-tree/model and what is a name of dtb?
[12:39]  * marvin24 has to boot up first
[12:39] <hrw> cause on Chromebook it is 'Google Snow' + exynos5250-snow.dtb so your hook for copying DTB may not work
[12:40] <hrw> works
[12:46] <marvin24> hrw: model is "Toshiba AC100 / Dynabook AZ"
[12:46] <hrw> thx
[12:46] <marvin24> so this would match the old fastboot entry in the db
[12:46] <marvin24> while /proc/cpuinfo gives "nVidia Tegra20 (F..D..T)"
[12:47]  * marvin24 needs to go to the car garage ...
[12:48] <hrw> Bug #1164484
[12:48] <ubot2`> Launchpad bug 1164484 in flash-kernel (Ubuntu) "Add support for checking Device Tree model name" [Undecided,New] https://launchpad.net/bugs/1164484
[13:29] <ogra_> hrw, i dont think that patch will fly, you completely ignore the device DB
[13:31] <ogra_> hrw, you rather want an entry for each supported DT device in the DB and tell it to use DT ...
[13:32] <ogra_> instead of ignoring *all* checks by just runing "if ! check_supported "$machine"; then"
[13:34] <hrw> ogra_: I do not ignore DB
[13:34] <ogra_> check_supported checks the DB
[13:34] <hrw> yes
[13:35] <ogra_> you *want* that and a proper DB entry
[13:35] <hrw> ogra_: so for all Tegra devices you want DB entry?
[13:35] <ogra_> imagine machines with DT and NAND ... or special bootloader setups
[13:36] <ogra_> for now you only need one for the ac100 ... andf it needs to switch between the old and new ways
[13:36] <hrw> ok, I start to see
[13:36] <hrw> hangout now - be back
[13:36] <ogra_> since the distro doesnt use marvins DT kernel yet
[13:40] <hrw> re
[13:41] <hrw> ogra_: if distro supports DT platform with one kernel - add DT entry. if with several ones - remove DT entry, add DTnames entries
[13:42] <hrw> or we can change check to: grab cpuinfo, check for DT, check for DTName = use if present, use DT if not
[13:42] <hrw> please add comment to the bug
[13:43] <ogra_> hrw, yeah, second option sounds good
[13:59] <marvin24> can we also add wildcards to the machine detection? or is this too dangerous?
[13:59] <marvin24> currently, it seems we only detect exact matches: if [ $value = $machine ];  ...
[13:59] <ogra_> i dont think the code can handle that
[14:01] <marvin24> something like [[ $value =~ $machine ]]
[14:01] <marvin24> (don't know if dash handles this)
[14:19] <marvin24> arr, no regex in dash
[14:24] <hrw> dash lacks everything and more
[14:25] <Rjs> I have no idea what you're talking about, but just in case this helps: all Bourne shells should support case which supports matching by glob patterns (not regexps)
[14:25] <Rjs> e.g: case "$value" in foo-*) echo match ;; *) echo no match ;; esac
[14:25] <hrw> marvin24: grep -e?
[14:28] <marvin24> hrw: maybe one should just replace dash by grep which has more features ;-)
[14:32] <hrw> ogra, marvin24, ppisati: http://paste.ubuntu.com/5676804/ then
[14:32] <Rjs> "case" is I think the standard thing to use for wildcard matching in shell scripts, unless you specifically need regexps instead of glob patterns; grep is quite complicated to use in comparison (something like  if echo "$value" | grep regexp >/dev/null 2>&1; then  except if value begins with -, and I may have forgotten some other detail too)
[14:33] <hrw> Rjs: if [ -n "`echo something|grep`" ]; then ;D
[14:34] <hrw> I have it in one of my scripts...
[14:34] <ogra_> lool, any opinion about hrw's patch ? ^^^
[14:35] <Rjs> the case equivalent would be something like: case "$machine" in *device tree*) machine="$(get_devicetree_model)" ;; esac
[14:36] <Rjs> (though $(...) is also non-portable, should use `...` instead)
[14:38] <Rjs> though if the script is complex enough to have user-defined functions, you could possibly consider just specifying /bin/bash and forgetting about portability :) (unless it's used somewhere where it's possible that only dash or e.g. busybox sh is available)
[14:39] <marvin24> hrw, ogra_: still fine I think
[14:40] <marvin24> I'll do some more tests in the next days
[14:40] <marvin24> maybe I can also solve the regex problem ;-)
[14:44] <hrw> Bug #1164484 - v3 added
[14:44] <ubot2`> Launchpad bug 1164484 in flash-kernel (Ubuntu) "Add support for checking Device Tree model name" [Undecided,New] https://launchpad.net/bugs/1164484
[14:54] <lool> hrw, ogra_: Might be best to call this device_tree_model instead of machine
[14:56] <hrw> lool: and add zillion of 'if/else/fi' in code everywhere?
[14:57] <hrw> lool: machine is also wrong named then - should be proc_cpuinfo_hardware
[14:58] <lool> hrw: machine is the historical name of it in the code and of the command-line override
[14:59] <hrw> lool: machine is also variable which tells which entry from deviceDB to use - right?
[14:59] <lool> Yes; currently these are real Hardware names though
[14:59] <hrw> lool: it was Yes/No question
[14:59] <hrw> lool: so what my patch does is just expanding ways of checking for names
[15:01] <hrw> lool: otherwise we will go back into flash-kernel < 3 version where we had huge selects instead of database
[15:04] <lool> hrw: It's just that I'd rather grep the db for model entries
[15:04] <lool> hrw: e.g. search for DeviceTree-Model: xyz in the db
[15:05] <hrw> good point as well
[15:06] <ogra_> lool, yeah i think thats what i said above too
[19:15] <marvin24> mmh, Xorg on raring crashes
[19:16] <marvin24> paste.ubuntu.com/5677653
[19:16] <marvin24> I've seen something like this before
[19:16] <marvin24> when pci is missing
[19:22] <marvin24> indeed, pci probe
[20:02] <ogra_> marvin24, hmm
[20:03] <ogra_> segfaulting isnt nice though ... and it works  on todays ac100 image
[20:05] <ogra_> oh, indeed ... 3.8 ...
[20:39] <tassadar_> ogra_: do you have nexus7 with ubuntu desktop laying around? Would you please show me it's cmdline?
[20:40] <ogra_> i dont ...
[20:41] <tassadar_> okay, no problem
[20:41] <tassadar_> it's just that the prebuilt boot.img has console=tty0 in cmdline, and the installer then changes it to tty1, and I'm not sure which one is correct
[20:41] <ogra_> it is the cdmline the bootloader sets plus "root=/dev/mmcblk0p7 ro quiet splash"
[20:42] <ogra_> doesnt matter
[20:42] <ogra_> as long as its a tty
[20:42] <ogra_> the prob is that the bootloader puts console= in
[20:42] <ogra_> without any value
[20:43] <ogra_> that confuses a few things
[20:45] <marvin24> ogra_: I think we can fix it - just a moment
[20:45]  * marvin24 compiles new xserver on his ac100
[20:51] <ogra_> marvin24, give it to tjaalton in #ubuntu-x
[20:51] <ogra_> (or mlankhorst if it takes until tomorrow)
[20:51] <marvin24> ogra_: ok, thanks - will try
[21:20] <marvin24> ogra_: no reply - I guess they will just point me to the bug tracker
[21:21] <marvin24> basicly, a simple NULL pointer check is missing
[21:21] <ogra_> yeah, i see it in the channel
[21:21] <ogra_> i guess he went to bed already
[21:21] <marvin24> yes, also time for me
[21:21] <ogra_> ha, no, he didnt
[21:22] <marvin24> dentist is waiting for me late in the night
[21:22] <marvin24> oh
[21:30] <wookey_> what's the gpu in a nexus 7?
[21:31] <wookey_> and an n900?
[21:31] <wookey_> I need to build a gles app and am wondering which way lies least pain
[21:32] <wookey_> bloody gpu people are such a PITA, making everything painful
[21:32] <ogra_> nexus7 is tegra
[21:32] <ogra_> 3
[21:32] <ogra_> if yu use the ubuntu image you even have a proper driver preinstalled
[21:32] <ogra_> n900 should be PVR ... no idea what version, no idea about drivers
[21:33] <wookey_> I thought the ubuntu image used !X of some sort?
[21:33] <gildean> did you see this about tegra-drivers: http://www.phoronix.com/scan.php?page=article&item=nvidia_tegra_3d&num=1
[21:33] <ogra_> the desktop image uses X ...
[21:33] <ogra_> we have two for the nexus7
[21:33] <ogra_> wookey_, https://wiki.ubuntu.com/Nexus7/Installation
[21:33] <ogra_> thats for the desktop image
[21:34] <ogra_> (i would do the manual install ... but make your choice)
[21:34] <wookey_> right I read tha tpage yesterday - I didn't notice anything about two diff images
[21:34] <ogra_> gildean, yeah
[21:35] <gildean> ogra_: didn't take them long, only like three years
[21:35] <wookey_> OK and 'desktop install' means 'normalish ubuntu'
[21:35] <ogra_> wookey_, https://wiki.ubuntu.com/Touch/Install ... thats the android based Ubuntu Touch
[21:35] <ogra_> right, desktop means literally desktop :)
[21:35] <wookey_> OK, just 'desktop on a small screen'
[21:35] <ogra_> yep
[21:35] <ogra_> sadly not scaling very well :)
[21:36] <wookey_> so you'll still need a keyboard and mouse to do various things
[21:36] <ogra_> yup
[21:36] <ogra_> there is an onscreen kbd
[21:36] <wookey_> OK. I was hoping that I could use the touch UI and make it work reasonably for the small set of about 3 programs I need to run
[21:36] <ogra_> but for programming you want a real one or at least ssh
[21:37] <ogra_> sure, use the touch image for that ... but that doesnt use X
[21:37] <wookey_> but as you say with onscreen keyboard and unity and some tweaking maybe the desktop version can be OK
[21:37] <wookey_> problem is that  the main app uses wx and wx needs X (I think)
[21:37] <ogra_> you have the choice :)
[21:37] <ogra_> ah, yeah
[21:38] <ogra_> that keeps you stuck on the desktop image
[21:38] <wookey_> OK. that clears some things up anyway.
[21:38] <wookey_> It does seem like the least-painful option for now
[21:39] <wookey_> hopefully it'll be a bit less crufty than debian on an openmoko :-)
[21:39] <wookey_> which was pretty damn crufty
[21:41] <ogra_> heh
[21:41] <ogra_> it is snappy and pretty usable actually
[21:42] <ogra_> i used it as my living room tablet and as ebook reader ... worked fine for that
[21:42] <tassadar_> the stuck-mouse-button bug is still there unfortunatelly :/
[21:43] <ogra_> yeah, there is a fix upstream though
[21:43] <ogra_> sadly apparently hard to backport
[21:43] <tassadar_> yeah, saw the discussion on launchpad
[21:44] <tassadar_> but from what I can understand from that bug entry, it is set as must-fix before raring release, right?
[21:44] <ogra_> well, it was ... now touch came around ...
[21:44] <ogra_> we'll see
[21:44] <tassadar_> hm, yeah, and mir
[21:45] <ogra_> Mir wont enter the archive before release
[21:46] <tassadar_> no, but I suppose the nexus7 image doesn't have very high priority...or does this happen on all touchscreen devices, even PC?