=== XorA is now known as XorA|gone === zz_chihchun is now known as chihchun [07:17] good morning === albert is now known as Guest19957 === Guest19957 is now known as Phryq === yofel_ is now known as yofel [09:51] janimo, heh, i have what i think is the worst workaround i ever found ... for the sound init [09:52] an upstart job with: rtcwake -u -s 1 -m mem [09:52] I am also looking into it [09:52] costs 1sec boot time and makes the screen flash once during boot [09:52] and it works if I enable HDA_INTEL [09:52] (its a 1sec suspend) [09:52] but volume if off on start [09:53] I need to see how to turn that on by default on boot, [09:53] that should be solvable by a ucm setup [09:53] I tried amixer calls and to no avail [09:53] only from control center [09:53] but it looks like INTEL_HDA should be on (it is in Android) even if the hw does not seem to have HDMI connectors [09:53] you need to unmute the left and right channel of the speaker control separately i think [09:54] why did we switch it off again ? [09:54] i remember diwic asked for it to be off [09:54] right, I tried sudo amixer -c 1 cset numid=1,iface=MIXER,name='Speaker Playback Switch' 1,1 [09:54] no idea, the whole ALSA stack confuses me [09:54] what are controls and simple controls, are they both neede, is controls a superset? [09:55] so many ways to set alsa (alsactl restore, amixer, alsamixer, control-center) [09:55] the fact there are 140+ controls is of great help as well :) [09:56] yeah, thats awesome, isnt it ? i bet you could turn the nx7 into a recording studio if you could attach the right peripherials :P [09:56] no idea what those things do, or why are they all exposed. [09:57] and I thought the ac100's sound options were complicated [09:57] haha [09:57] I'll send a config patch to kernel devel and then see how to debug further but should hopefully only be some alsa config file tweaking [09:57] and the card becomes the second, as hda will be card0 [09:57] as in Android [09:58] never heard of rtcwake before, good to know [09:58] check the chanelog first, there was a reason why diwic wanted it off [09:58] yes, he just said it is useless as we do not have HDMI [09:58] hmm, k [09:58] but it is on in Android and seems to be needed for suspend [09:58] as long as it doesnt cause mad wakeups etc [09:58] it was just pruned as poart of simplifying config [09:59] yeah, then switch it on again [09:59] oh, btw i uploaded an ambient light script as well yesterday [09:59] it is probably just a tegra hw bit that needs to be poked for proper audio suspend even if not connected to anything [09:59] great [09:59] only GPS and camera missing :) [09:59] oh, and BT needs another deep look [10:00] yes, camera is looked at by nvidia (not sure of the status but I am talking to the dev - our own Bryan Wu) [10:00] is cyphermox on BT and GPS? (and NFC) ? [10:00] hehe [10:00] do we have NFC ? [10:00] * ogra_ wasnt aware [10:01] yes the device has it, fw in the blob collection [10:01] and no idea about cyphermox, but we will have some -desktop attendance on friday [10:01] not too important I'd say, webcam is the real important one [10:01] right and the xinput bug [10:02] yes, the webcam sensorwise, xinput overall showstopper [10:02] its not that bad, if you make sure to actually leave time between taps [10:03] i get through for a whole evening if i tap really carefully [10:03] i wonder if we could somehow just turn down the sensitivity to work around it [10:04] How is the update-initramfs triggers supposed to work? When installing precise on my armel target, I see a few packages that "update-initramfs: deferring update (trigger activated)" like it should. But after the kernel has been setup, all packages installed which triggers update-initramfs all makes update-initramfs run. Many times. Is this how it should be? [10:04] depends, packages can force a trigger execution [10:04] What can I do to debug this thing? [10:05] well, read about triggers i'd say :) [10:05] Well I don't see any difference in the triggers in the packages that run and defers and those which runs it immediately [10:08] If I do remember correctly, the kernel runs /etc/kernel/(pre|post)(rm|inst).d/ and thus forces update-initramfs to run. Could this be altering the behaviour of the triggers somehow? [10:20] I'm not enlightened by the dpkg-trigger documentation.. But you haven't seen that update-initramfs is run multiple times during installation on your systems? [10:24] sveinse: I generally only see it run multiple times when an apt run gets split into several dpkg runs to break loops or satisfy pre-depends, etc. [10:24] sveinse: A good indicator of that is often seeing the "Reading dpkg database... " stuff in your terminal backscroll. [10:25] sveinse: Triggers can't carry between dpkg invocations (for, I hope, obvious reasons), so you'll sometimes get more than one trigger from the same package in an apt run. [10:26] infinity: No, I dont think my runs are between dpkg invocations. It's all in the "Setting up ..." section [10:27] If it's a big long string of postinsts, yeah, I'd probably have to see it to debug what's happening. [10:27] It could be a dpkg bug, or it could be initramfs-tools' trigger is goofy. [10:27] Or it could be postinsts of certain packages calling it wrong. [10:27] How does dpkg decide when to run a trigger? [10:27] (The kernel forces it to run triggerless, but that's a different story) [10:28] Normally, it runs them at the end of a dpkg invocation, based on registered interest or delayed triggers (the latter, in the initramfs-tools case). [10:29] Anyhow, not going to get into this at 3:30am. But if you have some terminal logs that show the offending behaviour in action, feel free to reference them in backscroll, or file a bug and reference that or some such. [10:30] Just don't be offended if I decide to close it as invalid after looking into it. ;) [10:30] What it seems in my case is that a few packages triggers it, then dpkg runs the trigger. One more or sometimes two triggers it, dpkg runs the trigger once more. [10:30] * janimo just managed to get something that sounds like a drunk and angry R2D2 out of the nexus7 by randomly toggling things in alsamixer [10:30] need a way to turn it off, it persists across reboot [10:31] infinity: Well, I'm more like grateful. I've been struggling with this for a while now [10:50] janimo: you want to be careful with that ... I know someone who literally melted his chromebook by toggling alsamixer switches... [10:50] dmart, yes, I had read hrw's account [10:51] for a moment I had feared I may damage the speakers too [10:51] janimo: ucm profiles for chromebook are present in raring and in sru queue for precise/quantal [10:51] but it's back again now [10:51] hrw, I have no chromebook, it is the nexus7 that I was toggling alsa settings on [10:52] ah [10:52] hrw: Are the ucm profiles purely a userspace thing? [10:53] yes [10:54] janimo: really, it feels like the kernel should police any settings which can actually damage the hardware... but I don't know enough about alsa to know how to do that. [10:54] hrw: ^ [10:54] I need to update kernel as some fixes went to kernel [10:55] dmart, I agree, but maybe some hw can be broken in so many ways the kernel cannot catch all cases. No idea really [10:55] this may have been a simple bug/oversight, hrw? [10:55] It's possible I am missing some fixes ... I haven't updated for a bit [10:55] just like one could fry monitors with VGA poking, there may be root-only things that can damage modern hw [10:56] janimo: they fucked up "ASoC machine" source [10:56] janimo: sure, but that's still a bug in my view. I thought the ucm profiles were more about presenting the mixer settings in a more intelligible way, since the hardware-specific mixer config can be pretty complex [10:56] I know little about ALSA too, learned some the past two days but am still bewildered by the large number of concepts and config options [10:56] so you can connect wrong parts of audio chip to output [10:57] hrw: My guess was that the likely problem is that the hardware mixer allows you to connect two SoC outputs to the same analog sink [10:57] dmart: and one of them is digital iirc [10:58] hrw: oh! [10:58] hrw: I wondered if bad things could be made to happen by, say, connecting the left and right DAC1 channels to a single channel of the speaker. But I didn't really want to try that... [10:59] dmart: check my blog for exact steps [10:59] dmart: now my left speaker can only generate heat cause it is unable to generate sound anymore [11:00] hrw: on the plus side, you can now use /dev/heat to make a novel user interface... [11:00] dmart: but /dev/heat is symlink to /dev/stinkysmall [11:00] dmart: but /dev/heat is symlink to /dev/stinkysmell [11:22] I have a custom deb package which installs a hook into initramfs. This hook relies on a file from /etc. Now when I install this package the hook is put into the filesystem early (when unpacking), yet the /etc file is put in late (when setting up I guess). However, update-initramfs is run by other packages in between these two steps and that makes update-initramfs bork since its missing the... [11:22] ...file from /etc. How should I deal with that? === chihchun is now known as zz_chihchun [12:59] * xnox has just flashed nexus7 using... usb-creator [13:54] what's the state of ubuntu on the samsung chromebook? [13:54] any chance we'll have working video acceleration anytime soon? [14:23] pfui: hrw does samsung chromebook stuff. [14:28] xnox: hmm... seems to have a few relevant posts on his blog. thanks! [16:00] hi, all! I need connect nexus 7 with ubuntu under Windows via terminal, but the system asks for driver... Which one I need? [16:03] reisei: i'm quite ignorant about windows so not sure if this is up-to-date, but the linux kernel source has documentation at http://kernel.org/doc/Documentation/usb/gadget_serial.txt (search for "Windows") [16:04] * ogra_ has no idea [16:04] on ubuntu you can just run screen with the right args in a terminal ... or minicom, surprising that win needs actual drivers for a serial USB port [16:05] you'll probably need to write your own, since nexus 7 has it's own vid and pid [16:05] (meaning you'll have to write definiton file, which tells windows to use it's generic driver) [16:05] there is no generic usb serial drive in windows ? [16:05] *driver [16:06] yes, but you'll have to tell windows to use it on that vid/pid - that's what windows calls "driver" [16:07] it is in that doc Rjs linked [16:07] (I'm still ignorant but guessing:) the windows inf file that the documentation talks about is at http://kernel.org/doc/Documentation/usb/linux-cdc-acm.inf and seems to contain vendor and product IDs, so I guess you could change them there [16:07] ah [16:08] yeah, should be as easy as that, had to do that for one ACM USB thingy already [16:08] funny how that is "driver" for windows) [16:09] that file talks about something called usbser.sys, so I guess that inf file is really a configuration file for the generic driver named usbser.sys (I presume that's included in windows, since the doc doesn't speak about having to download it) [16:14] hmm, does the ubuntu nexus7 really have its own vendor/product IDs? as far as I can tell from my syslog, the vendor and product IDs in the inf file I linked to appear to be correct: vid 0x0525 and pid 0xa4a7 so I'm guessing that inf file should work as it is [16:14] my syslog has "New USB device found, idVendor=0525, idProduct=a4a7" from the time I still used the standard ubuntu kernel (I have later switched to the combined ethernet+serial gadget which has a different product id) [16:16] maybe it doesn't, that vid is "0525 Netchip Technology, Inc." and pid is "a4a7 Linux-USB Serial Gadget (CDC ACM mode)" [16:17] * Tassadar goes to look at that driver's source [16:20] That's so opposite to linux simpicity... [16:23] I don't get why they don't just use USB device class to find driver like Linux does [16:26] yeah, the vid/pid is hardcoded [16:27] apparently they donated some pids, "Thanks to NetChip Technologies for donating this product ID." [16:27] then you can just use the driver as is :) [16:47] Hi, I was recently thinking about getting an ARM device as my home server (irc, ftp, bittorrent, small http, etc). Cubieboard and some ODROID boards looks promising, but I even got as wild as thinking about Nexus 7. === XorA|gone is now known as XorA [17:07] Rjs: those look different to mine. [17:08] 484 + 'ID_VENDOR_ID': ('18d1',), [17:08] 485 + 'ID_MODEL_ID': ('4e40', 'd001',), [17:08] Rjs: ^^^^ for nexus7's i saw around. [17:09] and that's just standard google / nexus7 id's. [17:09] dont mix up kernel and bootloader though .... [17:09] ah! [17:09] the nexus reports different things in the different bootloader modes [17:09] how dumb is that :-( [17:09] and kernel wise it matters what is actually bound to the gadget setup [17:10] the pid is also different if you turn on/off the debug mode (adb) [17:11] XorA, not dumb, that whay the other end knows if it is in flash mode, media player mode recovery (with adb) etc etc [17:12] indeed under the assumption that you have a udev rule (or windows driver) that can handle that state [17:13] and the g_serial driver has the pid/vid hardcoded in drivers/usb/gadget/serial.c, if you wanna take a look [17:15] ogra_: there has to be a better way, making that sort of mess has no real justification [17:15] ogra_: other devices work fine with constant ids [17:15] tell that to android [17:15] i dont think thats actually nexus7 specific [17:15] at least for the bootloader side [17:15] its probably more a function of which lazy engineer did the integration [17:17] wooy, go with a board, the nexus7 would be a waste in such context [17:23] xnox, hrm, that upstart job is quite uglz [17:23] *ugly [17:25] xnox, and it will be executed for every USB device you ever plug in [17:26] ogra_: well, very soon now we will have upstart user session. [17:26] ogra_: then the job will move and run in the user session, if usb devices are plugged in. [17:26] yeah, still [17:26] ogra_: the alternative I had was: udev-rules with RUN+= [17:26] i think having a udev rule that triggers something in the user session would be better [17:27] apart from that cannot "spawn", if usb-creator is started the udev rules processing is blocked until usb-creator exits. [17:27] another option is to have: udev rules which does "start usb-creator" to launch the upstart job. [17:27] .... [17:27] but that's like two hacks instead of one. [17:27] yeah, no, well ... [17:28] ogra_: the trouble is that, udev runs at system level. And the hops to get DISPLAY & $uid are ugly =/ [17:28] ogra_: by the way upstart job is quicker to launch usb-creator than udev rule + shell wrapper [17:28] * xnox has no idea why. [17:30] less subshell calls probably [17:30] still, i dont like to idea to fire off that job every time you insert a usb device [17:31] there must be a more elegant way [17:33] i wonder if there isnt a more fine grained way to use the event .... i.e. some kind of filtering [17:37] =/ yeah that would be nice [17:37] ogra_: anyway, I did ask james hunt to review it and see if he can offer something better. [17:38] Note the bottom on upstart-udev-bridge manpage "This is a temporary tool until init(8) itself gains the functionality to read them directly; you should not rely on its behaviour." [17:38] yeah, well, we could have a udev rule that emits an event [17:39] so you filter on the lower level, and the upstart job just reacts to "nexus7-added" events [17:41] a udev rule with ... RUN+="initctl emit --no-wait nexus7-added" [17:42] we have that rule file already anyway [17:43] (or at least we should, for setting the udev-acl stuff to not need root access) [19:21] marvin24_, is your 3.8 ac100 kernel working well? [19:37] janimo: Thinking of updating raring to something modern? [19:38] infinity, sure, if it works. marvin24_ said he's working on a 3.8 port [19:53] janimo: yes, 3.8 works fine [19:53] but building a kernel package takes weeks ... [19:54] I hope I can upload something on the weekend or so [19:54] marvin24_, great. Same gitorious repo? [19:54] weeks really? [19:55] do you have errors building it? [19:56] janimo: it's still the kernel in my old repo [19:56] https://www.gitorious.org/~marvin24/ac100/marvin24s-kernel/ [19:57] some modules failed, yes [19:57] so I need to disabled them [19:57] then I got abi errors [19:57] turned out I need to specify "-eskipmodules" [19:57] after several tries [19:58] and each one is two hours and I'm doing it in my free time ... [20:18] marvin24_, I used debuild with -nc [20:18] so it does not clean the tree [20:18] before rebuilding [20:22] well, I use ccache (with --prepend-path=/usr/lib/ccache) [20:22] marvin24_, do you know if nvidia keep some sort of wiki or updates on what is mainlined and what is pending for tegra2 and tegra3? An overview of sorts [20:23] janimo: not that I know of [20:23] I think they have an internal list [20:23] but what's getting done, is mostly in a random order [20:24] in fact, the most painful stuff missing is suspend/resume [20:24] and more powermanagement stuff [20:25] also some simple stuff just takes very long [20:25] e.g. backlight support [20:25] did graphics support land already? [20:25] DRM [20:25] yes, it's included in 3.8 [20:25] but without backlight, only hdmi works [20:25] funny [20:25] I think the backlight code is discusses for nearly one year now [20:26] and still no conclusion [20:26] do you know whether tegra2 or tegra3 is more completely supported in mainline? [20:26] so you carry the backlight code in your ac100 branch? [20:26] I think they are pretty inline [20:26] yes, I just one of the discussed implementations [20:27] but that's already outdated [20:27] in fact, now they wait for some generic framework [20:28] they have working 3.8 code for all things just not mainlined though? [20:29] yes [20:29] the way it needs to be integrated into kernel is, well, complicated [20:30] ok, thanks. Checking your branch out now [20:30] in fact, you just need to program some gpios [20:30] but there is no generic interface for this yet [20:30] and upstream does not like soc specific backlight ... [20:31] very long, sad story [20:43] marvin24_, does the 3.8 kernel require uboot or is the defautl ac100 bootloader enough? [20:59] janimo: both should work, but need different configs [21:00] fastboot needs cmdline from kernel and u-boot needs kernel command line from u-boot [21:00] but I don't plan to support 3.8 kernels with fastboot [21:01] 3.1 supports both [21:05] janimo: http://tinyurl.com/b55syst [21:05] this is what I have for now [21:05] against raring 3.8 kernel [21:06] ac100 specific patches are still missing [21:06] but compiles at least [21:08] marvin24_, nice. How many ac100 pacthes are there? [21:10] well, my linux-ac100-3.8 branch contains 25 patches, mostly nvec specific [21:10] but in fact, mainline also boots without any patch, but you will get no backlight ... [21:10] this patch changes a few other arm flavour's config files, probably a side effect of using the config updater scripts [21:11] yes, kernelconfig editconfig ... [21:11] I think it would be cleaner as a first step to have a dedicated tree, not based on the current kernel source [21:11] as it is unlikely they will take patches for this [21:11] I don't expect ubuntu to take patches for tegra [21:11] so a new linux-tegra package without any other flavours [21:11] because they cannot support it [21:12] right, just mentioning the resulting kernel would be cleaner than this patch suggests [21:12] if we had this kernel in raring would we need to use uboot on the ac100 then? [21:12] yes [21:13] I need to patch the debian dir anyway [21:13] isn;t that complicating the installer besides adding one other package to maintain? [21:13] and most is because of the abi stuff [21:13] I understand preferring to work with uboot but is fastboot support complicated? [21:14] yes, because I don't have the source ... [21:14] I'd like us to use this in raring but will need to speak to ogra to see whether it is a lot of effort to adapt to uboot [21:15] cannot whatever 3.1 does be emulated in 3.8 without knowing what fastboot does? [21:15] https://launchpad.net/~ac100/+archive/ppa/+packages has u-boot package already [21:16] janimo: well, I prefer minimal patches [21:17] why do you want fastboot? [21:17] marvin24_, oh just so 3,8 is a drop-in replacement for 3.1 [21:17] so we do not need any extra testing or image work [21:17] and not introduce a new uboot flavour for the ac100 only [21:18] it also causes extra work to support fastboot [21:18] nothing against uboot per se, just keeping changes minimal as you say :) [21:18] I'm not sure how to adapt 3.8 to make it woking with fastboot [21:19] and to make installation similar to previous cycles [21:19] would this also be nvflash of a bootimg and boot it? [21:19] (except chaning the krnel config) [21:20] no need to flash, as we planed to use tegrarcm [21:20] in fact, once ogra said that he won't put more work on the ac100 port [21:21] we decided to restart from something clean [21:21] I know this causes more pain for users, but less for us [21:26] also u-boot needs a new partition table because otherwise it cannot load the kernel [21:26] and this disables nvflash [21:28] because fastboot expects some proprietary partition table [21:54] Now, to get Ubuntu on the Toshiba A*T*100.. haha [21:54] I've got a fully-functional FS. No working kernel... [21:56] Do know how to kill the Android GUI stuff to get X working, via ADB shell, but a pure native way would sure be nice... [21:59] Wait, do I need U-boot to boot Ubuntu? Or is a Fastboot-based system OK? [22:06] hey, yo, where do i find like a this thing: http://packages.ubuntu.com/ but exclusive to arm [22:10] anyone? [22:13] is there even an apt repository for arm devices? [22:18] questionguy: http://ports.ubuntu.com/ [22:23] thanks a ton! [22:26] questionguy: It's a longstanding bug/misfeature that packages.u.c doesn't list ports, but you can see that the same packages exist on all arches by going to, say, launchpad.net/ubuntu/+source/ [22:38] infinity: yeah i literally thought that i would just find it by clicking around, and its completely inexcellent that it's so well hidden [22:38] but it's simple enough to remember, having seen it [22:42] Heh, should've known that.... [22:44] questionguy: Of course, if you have an Ubuntu armhf system installed, 'apt-cache search' is your friend. [22:45] yeah, i'm of course aware of that functionality, but i don't have one setup, and trying to see if this is a suitable distro, and indeed, it is [22:47] hey all, I've been told that 13.04 is supposed to work nicely on the arm-based chromebook. Is there a better way of installing 13.04 than installing the hacked-shell-script-12.04, and upgrading? (I've tried to upgrade before, that went poorly to say the least) [23:09] So, where's the best place to get kernel help?