[01:20] hrw: are you there? [01:50] … === Crisco is now known as zz_Crisco === asac_ is now known as asac [06:00] hi all [06:01] any one know , how the gnome-rdp can be installed in the ubuntu-arm working or omap4-blaze .? [06:02] ranjith: probably the same way as any other package [06:03] I ahve not yet installed any package in ubuntu-arm .. is it same as how we do in normal ubuntu ..? [06:04] yes [06:04] just other architecture === jacquesdptd is now known as jacquesdupontd [06:08] ok [06:08] so that means the installation will work with the apt-get install ..? === jacquesdptd is now known as jacquesdupontd [06:46] while doing sudo dd bs=4M if=ubuntu-netbook-10.10-preinstalled-netbook-armel+.img of=/dev/ , will it create two parttions in the 4gb sdcard or three, [06:47] I had instaled the ubuntu-arm on omap4-blaze last day, but while trying to install it again, now its failing. its creating 3 parttions in my card and not booting .. [07:04] I do not know - I do not use ubuntu images [07:06] hrw: is there any other way than using this image ..? [08:52] hi === ogra_ac_ is now known as ogra_ac [11:49] Is there a mailing list similar to this channel? [11:55] sveinse: ubuntu-devel is used now [12:08] hey guys anybody in U.S heard about a U.S missile launch those days? [12:30] morning [12:33] morning [12:34] Is there a way to build apps with the cross compiler and make the linking against userspace target [dynamic] libraries? [12:36] I'm trying to build a Qt application, which I am able to fully build and link with a cross compiler. But as soon as I link against other libs which is installed on the target Ubuntu ARM, the linker gets confused [12:37] E.g 1) On target /usr/lib/libpthread.so is a linker script referring to "/lib/libpthread.so" which confuses the cross compiler, as this is then referring to the host lib [12:39] So I fixed that by modifying the scripts and the linker is partly happy. When I try to link against, say libpulse.so, it requires a lot of other libs, like libz.so, which the linker cannot find without explicitly naming -lz when linking [12:39] It gets me to wonder: How is it intended to use the cross compiler should be used and what option have i missed? [12:39] Is these problems at all familiar to anyone? [12:41] On target native building is really not an option for us, because it pratically renders the build servers useless... [12:42] One option could be to make a ARM rootfs with the -dev packages installed, and inject the cross-compiler into it and then use chroot. [12:42] But this seems like hairy methods to me [12:43] and it's still slow, real cross should be the best option [12:43] maybe hrw can help you better [12:43] but I believe this will only be fixed with multiarch support [12:45] sveinse: check for xdeb in wiki.linaro.org [12:46] * hrw -> confcall [12:47] rsalveti: hello [12:51] janimo: hey [12:51] rsalveti: was looking around what tasks to pick :) [12:51] was looking into the haskell FTBFS's [12:51] and to the linaro qemu thing [12:52] hrw: anything particular I'm looking for on the wiki? [12:52] since my arm board arrives tomorrow, I think I'll try out the install in qemu first [12:52] janimo: ok, should be ok with qemu [12:52] https://wiki.linaro.org/UsingXdeb [12:52] if you use the same qemu as linaro and the omap3 kernel [12:53] rsalveti: yes, using qemu from linaro ppa, omap3 10.10 image [12:53] and will look for a kernel image [12:54] bah [12:55] http://packages.debian.org/experimental/libreoffice [12:55] no armel builds [12:55] ogra_ac: I'll look into OO as well [12:56] i guess you have to wait for the kdelibs stuff to be done [12:56] s/OO/LibO/ [12:56] it wont build otherwise [12:56] sure [12:56] ah [12:56] just when it is time [12:56] so is the toolchain fix for Qt released then? [12:56] well, i'm not sure we will sync it into natty [12:56] LibO ? [12:56] (libO i mean) [12:57] hmm, past freeze or why? [12:57] they have 3.3 RC1 out [12:57] the toolchain fix was actually there before A1 but nobody noticed (the changelog entry was a bit weird) [12:57] and seem to be progressing nice, and the deb packager is up to date [12:57] well, i have no idea what the TB decided [12:57] so QT stuff should just need a 'try rebuild' ? [12:57] so i dont know if we ship OO.o or libO [12:57] ogra_ac: ah, was there a TB meeting regarding this [12:57] * janimo missed it :( [12:57] no idea [12:58] but i would expect this to be a TB decision [12:58] I hope we'll use LibO, much nicer upstream, much less work for ubuntu packager [12:58] yes [12:58] i was just writing some letters with zoho and its really unusable [12:58] that made me look at the debian libO stuff [12:59] but isn;t current OO in natty working? [12:59] should work afaik [12:59] LibO takes many hours to build on a decent x86 desktop [12:59] but my ac100 has only 4G free, i dont want to waste that space on an office suite [12:59] I wonder how much it is on an arm borad [12:59] so i decided to use what we ship on arm [13:00] which is zoho [13:00] but that has multiple issues [13:00] I did not know about zoho [13:00] is that FOSS too? [13:00] its a web sevice [13:00] similar to google docs [13:00] no deskto pcomponent at all? [13:00] ok [13:00] there is mime integration and .desktop files we ship [13:00] I knew about it but though maybe there some glue for the ubuntu desktoip (indicators whatnot) [13:01] JamieBennett did do that before he moved to linaro [13:01] nobody really improved it beyond that [13:01] but the issues i had were rather on the zoho side, not with our integration [13:01] yes [13:02] main issue is that it hangs eternally once you try to use copy/paste [13:02] OO.o takes 36h to build on armel [13:02] i wouldnt expect libO to be much different [13:02] buut as soon as we switch to panda buildds that will change significantly [13:03] (should reduce the time to 1/2) [13:06] hrw: Can I build production apps with xdeb, or is it just for convenience (i.e. experimental) ? [13:07] experimental rather [13:07] ubuntu and crosscompilation does not match [13:08] so I've figured on my own.. [13:08] sveinse: never heard of that mistical 16core 5GHz arm cpus and mainboard which takes 8 of them + 128GB of 3333MHz ddr3 ram? [13:09] I heard that ogra_ac uses such as desktop [13:09] ?? [13:09] > [13:09] heh [13:09] i wouldnt mind to [13:09] would be wuieter than my laptop [13:09] neither would I [13:09] hrw: I should propose this to the purchasing and the the IT dept... Guess they won't like :D [13:09] *quieter [13:12] Kind of ironic I would say. We have a large build server to our disposal in this project, but cannot use it properly to our benefit: cross-compile is dodgy, qemu is inefficient, running on target... :( [13:16] hrw: is it only that ubuntu and xcompilation do not match or xdeb itself is not mature on any platform [13:17] xdeb is not mature [13:17] it is improving [13:19] Well on the flipside, my impression is that Ubuntu ARM is pretty stable, since it relies on only native compiling. [13:21] one of the reasons why we chose Ubuntu as system for our project (over OE) [13:32] Are there any risks in cross compiling an application and then exporting it to the target in relationship to which cross compiler is used? E.g. when the app dynamically relies on libc, I cannot choose cross compiler (CodeSourcery vs. armel-cross) freely since these are build against specific libc libs, right? [13:33] (when running Ubuntu ARM on target, using libc installed from ubuntu) === xfaf is now known as zul [14:42] ubuntu 10.10 provides armel cross compiler [14:43] but is has a bug 684625 which I have a fix for so matter of 2 weeks? [14:43] Launchpad bug 684625 in gcc-4.5 (Ubuntu) (and 2 other projects) "libc6 is compiled for armv5 instead of armv7a (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/684625 [15:02] ndec, holding on the phone [15:03] davidm: sorry. i am a bit late. i am coming [15:03] ndec, NP [15:03] ndec, was worried I had messed up the time somehow [15:15] * rsalveti lunch [15:40] ogra_ac: hey there [15:41] Trying to understand the initramfs thing ... where does run-init come from? The only source I know of is klibc [15:42] npitre: ah, the other guys here thought you do [15:43] (wrong channel) [16:37] dmart: what is it you don't understand ? [16:44] dcordes: I don't understand ogra's statement about run-init being linked against glibc ... if run-init is build from the klibc package ...? [16:44] /win 5 [16:54] rsalveti: Did you know that Friday's (Alpha 1) image doesn't have networking? [17:00] GrueMaster: I only saw that the nm-applet icon wasn't there [17:00] that's kind of ok for alpha, you still can fire dhcp by hand if you need/want [17:01] but would be good to reproduce the issue, fire a bug and debug [17:01] seems that the gnome-panel is not that stable either [17:01] some times I get seg fault while loading it [17:01] just need to find time to debug and report these issues [17:02] Not a big deal for A1, but this kind of stuff needs to be listed in the release notes. This is one of the reasons why I hate last minute respins. [17:03] sure, but we did the respin because otherwise we would basically miss it [17:03] Friday was supposed to be dedicated to blueprint work. Instead I had to pack up a panda & monitor to take downtown to the PDX meeting so I could try to figure this out. [17:03] I understand the reasoning behind the respin. Never said I had to like it. :P [17:04] But so far, I have had little time for blueprint work, due to respin testing, -proposed testing, and other interrupts. [17:05] * GrueMaster wonders if someone added an automated test somewhere to test his sanity. [17:05] yeah, I also got quite busy with stuff I wasn't planning for [17:05] GrueMaster: if you find time, check if today's image also have this issue [17:06] I already pulled it. Will look at in a little bit. (part of my morning routine). [17:09] ok, let me know if you're still facing these issues, will try to debug later then [17:41] ogra_ac: abiword doesn't work for you? ac100 is going well then? [18:36] ogra, ogra_ac about usb-imagewriter or so, is there a good reason why it can't use compressed images and decompress them? [18:41] Neko: You can file a wishlist bug for it. The images it was originally designed for are x86 .iso type images though. It really doesn't do a raw-write as needed by our preinstalled images. [18:42] not Startup Disk Creator [18:42] usb-imagewriter [18:43] https://bugs.launchpad.net/ubuntu/+source/usb-imagewriter [18:48] I don't think it has been worked on in over a year, since usb-imagecreator became the default for Ubuntu. [18:49] And ogra is out until the end of the year (may make an appearance now and again, but doubtful). [18:52] usb-imagecreator doesn't work for arm netbook images which are still shipped as .img [18:53] I can't believe Ubuntu armel is still a second-rate distribution after Mark waved an AC100 round and said "this is the future!!" [18:53] is he being overridden by committee or something who only care about amd64? [18:54] well, as mark said, that's the future [18:54] not now hehe [18:54] but the idea is to get closer and closer with other archs [18:55] startup disk creator only writes to partitions not to disks [18:55] it's really clumsy :( [18:56] Like I said, it was designed for .iso images to be written to USB. [18:58] I guess it's time to write a new tool for it [18:58] sounds like a fun project for me :D [18:59] BTW does Ubuntu hold the same "ARGH IT HAS TO BE GPL!!!!!" policy of Debian? [19:00] lol [19:00] okay let me rephrase that in a less funny way [19:01] does Ubuntu hold the same "ARGH IT HAS TO BE GPL!!!!" policy as Debian, or comparitively the "OMG IF IT'S NOT BSD WE SHOULD REWRITE IT" of Open/FreeBSD for example? [19:01] because to be honest the BSD tools are much better than the GNU ones.. BSD tar is awesome for example, since it uses libarchive [19:01] Neko: Why not pull a branch of usb-imagecreator and enhance it? [19:02] I'm apt-get sourcing it now :D [19:03] I just figured maybe it would be a cute idea to use the bsdtar and bsdcpio by default and make tar and cpio wrappers around it to mess with what the GNU differences are [19:03] they can be faked.. [19:05] it reduces the footprint by a little bit, compression is automatically detected and extensible, it really is wicked === Baybal__ is now known as Baybal [19:22] rsalveti: Something changed recently in natty as to networking. I tried re-adding "auto usb0 ; iface usb0 inet dhcp" to /etc/network/interfaces and it works again. [19:22] I don't have manifests for the images prior to A1 though. [19:23] GrueMaster: ok, but that should work, are you able to see the nm-applet now? [19:23] After adding the above two lines, yes. [19:23] And it connects. [19:23] hm, weird [19:24] Although the nm applet icon appears to be a disconnected wifi icon. [19:24] Should be two arrows (up & down) for ethernet. [19:25] iface usb0 inet dhcp probably says to nm to avoid managing it [19:25] hmm/ [19:25] Will try w/o. [19:25] on maverick we don't need to put these lines and it works ok, as expected [19:26] we used to. [19:26] need to check the nm log to understand why it's not calling dhcp at the interface [19:26] GrueMaster: check /var/log/daemon.log [19:26] I wrote a script to fix images prior to them working properly in mav. [19:26] ok. rebooting, so one sec. [19:27] hmm. Dropping "iface usb0 inet dhcp" fails. No nm applet. [19:28] so it's probably failing to manage the usb0 interface [19:28] can you paste me the logs, since the boot? [19:29] Erm, give me a sec. No network, no pastebinit. [19:32] GrueMaster: give dhclient usb0 at serial [19:32] You assume I am using a serial console. [19:33] I'm getting it online. Just need to install pastebinit. [19:35] Grrr. universe is still not activated in the image. [19:41] rsalveti: http://paste.ubuntu.com/540406 [19:43] GrueMaster: this is with or without the modification you made? [19:43] Should have both. I don't think the file changes between reboots. [19:44] My changes would be lower down the line. [19:44] GrueMaster: Dec 6 02:44:58 sycamore init: network-manager main process (623) killed by SEGV signal [19:44] not good [19:44] first error [19:44] nm-dispatcher.action: Script '/etc/NetworkManager/dispatcher.d/01ifupdown' exited with error status 1 [19:45] Yea, I'm seeing that a lot as I scroll down. [19:45] first thing would be to check why this script is returning error [19:47] when you added your lines, nm probably decided not to manage the interface, and then it didn't get the segv [19:47] nm is probably calling this script with usb0 [19:49] Ifupdown: get unmanaged devices count: 1 [19:49] here's where nm decided not to manage the usb0 interface [19:50] GrueMaster: so our problem now is why nm is getting segv when trying to init the usb0 interface [19:50] could be because it doesn't expect the script to return an error [19:51] I'm comparing with my other panda running maverick. [19:54] * rsalveti is updating his natty image [19:56] I tried the script manually with all 4 cases it uses and haven't seen an error. [19:56] Will reboot w/o auto usb0 settings. [20:00] If I didn't know any better, I would think that it is going ipv6 only. [20:02] will try to reproduce it here when it finishes the update [20:10] argh, sd card is too slow [20:21] rsalveti: BTW: I noticed that there are huge difference between sd cards, even within the same class rating, because their latencies varies a lot. [20:22] It's a challenge for us when we are sourcing sd cards because we need the right one, but its selection parameters is not listed in the card's specs [20:24] I went to my local gadget store and bought a new SD card, and it was totally useless. It's read and write speeds were allright, even better than my old card, (I did verify) but the latencies are 5-7 times slower than my old. [20:25] Ubuntu was going from useful to useless [20:25] sveinse: yeah, true, problem is that I cannot find many different sd cards around [20:26] mostly they are from kingston [20:26] that's why I have 2 usb disks around, currently running with maverick [20:26] a *lot* faster [20:27] yes, the slow card was in fact a kingston. The old was a sandisk. I even tried a transcend bundled with my HTC. It's faster! (despite being a low-price card) [20:27] cool, nice to know [20:28] Are you modifying the CHS layout of the card? [20:29] Some have proposed that doing so can really confuse the build in flash translation layer (FTL) since it needs to wrap 512b sectors into x kb flash sectors. Changing the CHS layout would probably make the sector requests out of order and thus creating a *huge* amout of erase cycles [20:30] interesting, never heard about that [20:32] I havent confirmed if its really like this yet, though. In light of our commercial sourcing, I think I will ask specifically to the selected vendor about it to confirm/deny it. [20:32] ok [20:32] sveinse: kingston just brands cards - atleast it was that way some time ago [20:34] hrw: I think so too. And I also believe the card available at your local computer store are mostly low-price and low on performance. [20:34] I run ubuntu on sata disk connected though usb [20:35] I also did that, but the USB stack died a couple of times and killed the FS :( [20:35] but usb on pandaboard is not as fast as I woule too [20:36] I experience NFS being more stable, albeit slower [20:37] depends - on some devices it is faster then local storage [20:40] hrw: I trust I can rely on that the host's libstdc++6-armel-cross and libc6-armel-cross are in sync/ABI compatible with the native armel counterparts? [20:40] yes [20:40] sveinse: same sources, same configs, same compile flags [20:41] excellent [20:41] sveinse: but current one are broken [20:42] hrw: In what way? Do you have a reference to bug or similar? [20:42] normal are armv7, cross are armv5 [20:42] bug 684625 [20:42] Launchpad bug 684625 in gcc-4.5 (Ubuntu) (and 2 other projects) "libc6 is compiled for armv5 instead of armv7a (affects: 1) (heat: 8)" [Undecided,New] https://launchpad.net/bugs/684625 [20:44] rsalveti: I wonder if NetworkManager is having issues with the non-existent mac address that was fixed in 2.6.35-903.19? [20:45] GrueMaster: don't know, what was fixed is the normal support of setting up the mac address [20:45] but getting a segv is not that cool [20:45] hrw: Does this affect the cross compiled apps in any way? I manually specify -march & friends, and I only rely on dynamic libc/libstc++ [20:45] still waiting the update =\ [20:47] sveinse: should not for shared [20:52] hrw: In regards of bug #683832, Does this mean that Qt uses some inline asm that triggers the failure? [20:52] Launchpad bug 683832 in gcc-4.5-armel-cross (Ubuntu) (and 1 other project) "gcc fails to cross compile Qt (affects: 2) (heat: 12)" [Undecided,Confirmed] https://launchpad.net/bugs/683832 [20:52] yes [20:52] rsalveti: I'm manually updating to 2.6.35-903.19 to see if the mac address fix helps. [20:52] * hrw -> away [20:53] GrueMaster: ok [20:53] Would be nice if kernel/sru teams would get it released already. I spent part of my holiday testing that. [20:54] the sru released for kernel takes quite a while, I noticed [20:54] *releases [20:54] Only when it doesn't apply to security patches. I went around this cycle several times during Lucid with network patches for both dove & babbage. [20:55] GrueMaster: how can someone using an sd card update from one release to the other? it'll take hours! [20:55] a lot easier to backup and grab a new preinstalled image hehe [20:55] ~7 releases later, it was finally released into main. [20:55] ouch [20:55] I find using a local mirror helps immensely. [20:56] sure, but the main problem is not getting the packages, but installing them [20:56] dpkg uses the disk a lot, and that is really slow [20:56] Gah! Got distracted during reboot. HDMI switch moved to a different system, then this system came up with garbled display. [20:56] True. [20:57] But since these systems are mainly for development, it is easier to nuke & pave. [20:58] yeah [20:58] Interesting. Something in the panel (maybe the panel itself) is in a respawn loop. [20:59] GrueMaster: yeah, with segv [20:59] another weird segv issue [20:59] doesn't happen all the time [21:01] ok, finished the update, time to reboot [21:01] Hmm. Kernel -19 has no effect. Still get the error about permanent mac in the log and the SEGV. [21:02] ok, good to confirm [21:04] Wow, this is new (for me). I sometimes lose video in X. Have to switch to text console & back. [21:04] never saw that before. [21:04] GrueMaster: underflow? [21:05] GrueMaster: check dmesg [21:05] Yep. GFX_FIFO_UNDERFLOW [21:05] GrueMaster: known issue [21:05] Yea, I had heard about it. Just never saw it before now. [21:06] http://people.canonical.com/~rsalveti/maverick/kernel/es2/linux-image-2.6.35-903-omap4_2.6.35-903.18rsalveti2_armel.deb this kernel brings the changes needed to improve it [21:06] Is it more pronounced on ES2.0? That's what I'm currently testing on. [21:06] but as the commits are not in the best shape, and it's just a workaround, we didn't move it further [21:07] GrueMaster: yeah, probably because of a slower mem [21:07] ah. figures. [21:07] Hey. We have sunshine. Haven't seen that much all year. [21:07] Kind of cool. [21:09] :-) [21:09] Well, it is 1pm. Need food. [21:09] brb [21:41] hmm, dmart is gone [21:42] Neko, usb-imagewriter needs porting to udisks first, i dont mind to add a line that calls zcat instead of dd if it finds a img.gz suffix indeed [21:42] zcat can write to a block file? [21:43] see our installation instructions [21:43] I gotta get into GTK anyway [21:43] we need to write some tools to properly control power management and all kinds on the Smartbook anyway [21:43] turning off wireless/bluetooth etc. individually etc. [21:43] seems there is no clever way to do that in GNOME or anything [21:44] also to control HDMI and audio on the Nettop [21:44] there is no difference in "gunzip file.img | dd of=/device/foo" or zcat file.img >/device/foo [21:44] ugh [21:44] why would you write extra tools for any of that ? [21:44] ugh? [21:44] just fix integration with the existing tools [21:45] well not so much write extra tools as extra panels in the existing tools :D [21:45] as it stands though there is no existing tool for configuring HDMI settings [21:45] well, for gnome-power.manager you just need to make the kernel DTRT [21:45] DTRT? [21:45] oh that [21:45] yeah, for HDMI you should add something to the display settings [21:45] well sure there is a sysfs interface [21:46] or will be [21:46] but it should be generic enough that other machines with HDMI can use it [21:46] yeah most of it is setting values that go into the AVI Infoframe and to select HDMI audio source (I2S or SPDIF) [21:46] after all its just UI work and making sure your kernel sticks to existing standards [21:46] right now we're rewriting battery and display drivers though [21:47] HDMI audio is trivially done by a pulse profile (as long as your ASoC devide works right) [21:47] but you can run both [21:47] *device [21:47] sure you can run both [21:48] the idea is the hdmi chip is connected to both audio outputs. if you sink i2s to hdmi it converts it to hdmi. if you sink spdif to hdmi it spools it over hdmi [21:48] as long as alsa exposes them right to pulse [21:48] but pulseaudio doesn't have any idea on how to switch between them, there is no way to add a setting users can poke [21:48] it just makes sure it can use each device [21:48] sure [21:48] we use that on the pandaboard [21:48] there just needs to be a switch somewhere to tell the chip which bus it's gotta move audio from [21:49] right, thats a matter of the driver [21:49] we're taking the hint from the omap driver to add blocking notifier chains so they can all cooperate [21:49] just expose all controls in alsa and have a switch inside the driver [21:50] yeah, thats what omap does [21:50] ehhh you can't have alsa controlling the hdmi audio switch it's freakish [21:50] works fine on panda [21:50] we'd have to hack the ASoc and SPDIF drivers to talk directly to the SII9022 [21:50] right [21:50] thats where that hack should happen [21:50] well that's dumb it would not work on babbage [21:50] or any other board on MX51 [21:50] why would you lift it up to userspace and add latency [21:50] or MX53.. it's board specific [21:51] bad [21:51] but well [21:51] latency? [21:51] what are you talking about [21:51] make the kernel expose the right things and the userspace will behave right [21:51] you write a value to a sysfs file [21:51] it changes whether i2s or spdif is going over hdmi [21:51] its all already there [21:51] if it takes 5us or 5 seconds who cares [21:52] but why dont you do it like everyone else and expose the switch in the asoc driver ? [21:52] this isn't about somehow sending audio it's just a i2c register write [21:52] sigh [21:52] whs does it need to be an additional sysfs control instead [21:52] show me where it bloody does this in another driver then [21:52] where all userspace tools can already handle it right [21:53] look at the omap4 asoc driver in the omap4 kernel tree of ubuntu [21:53] url [21:53] (and probably talk to liam) [21:53] (ASoC upstream) [21:53] we're not upstreaming shit. this is a hack so we can get it working. [21:53] also known as lrg in here ;) [21:53] well, if you dont want help, dont ask him then ;) [21:53] up to you [21:54] maybe in 6 months we'll look for a fancy way of pushing it upstream but there's a good chance none of the drivers we're messing with now are even going into mainline, and the ones that are in mainline are broken as hell anyway [21:54] if you do a hack you will likely have to add more hacks to other areas (UI, userspace etc) [21:54] it's a waste of time thinking about it [21:54] why ? [21:54] just do it right and port that stuff forward later [21:54] because mainlining patches to one fucked up BSP driver and one broken mainline driver for this feature is a waste of time [21:55] we're not thinking of mainline right now [21:55] i'm not talking about mainline [21:55] upstream, mainline, whatever, it's the same thing [21:55] rivers, trains.. [21:55] i'm just pointing you to the guy who knows most about SoC audio and can help you [21:56] anyway, i'm on vacation ... [21:56] just took a quick look at mails [21:56] eh there is no omap4 soc driver in the kernel tree for ubuntu [21:56] feel free to send a patch for usb-imagewriter, I'll happily apply it if its sane [21:57] omap-hdmi maybe? [21:57] must be somewhere on the kernel teams git server [21:57] okay I see it, and you're talking crack. this is a specific driver to push audio over that bus. we don't need that [21:57]