**** BEGIN LOGGING AT Tue Jun 29 02:59:57 2010
Jun 29 03:39:14 * mozzwald is away: sleepytimes
Jun 29 04:43:06 * mozzwald is away: sleepytime
Jun 29 07:15:44 <hrw> morning
Jun 29 08:44:56 <zumbi> hi
Jun 29 08:45:36 <hrw> hi zumbi
Jun 29 11:04:38 <lool> GrueMaster: Hey there, I understand you test maverick omap3 kernels on beagles regularly; how stable is the mini-USB port for you as a host port?
Jun 29 12:00:11 <kai> lool: there's a big difference between different beagle revisions for the kernels I tried
Jun 29 12:00:38 <kai> lool: but arguably I didn't try kernels from maverick, just the stuff rcn-ee builds
Jun 29 12:01:27 <ogra> kai, thats massively different :)
Jun 29 12:02:31 <kai> ogra: I'm still sure that the fact that the same kernel behaves different on two different beagle revisions means this can happen as well for other kernels
Jun 29 12:02:49 <ogra> indeed
Jun 29 12:02:59 <lag> sebjan: ping
Jun 29 12:03:00 <kai> notably, otg seems more stable on revB
Jun 29 12:03:25 <sebjan> lag: pong
Jun 29 12:03:39 <lag> Hi sebjan
Jun 29 12:03:52 <lag> sebjan: bug 592295
Jun 29 12:03:56 <ubot2> Launchpad bug 592295 in linux-ti-omap (Ubuntu) "omapdss DISPC error: SYNC_LOST_DIGIT (affects: 1) (heat: 8)" [Medium,Confirmed] https://launchpad.net/bugs/592295
Jun 29 12:04:29 <lag> I believe this to be a regression issue imposed on us by one of your colleagues
Jun 29 12:04:35 <kai> arguably it's been running fine for quite a while now
Jun 29 12:04:52 <ogra> lag, i belive thats the wrong package it's filed against
Jun 29 12:05:05 <lag> sebjan: Mythri P K <mythripk@ti.com>
Jun 29 12:05:17 * kai re-lurks
Jun 29 12:05:18 <ogra> should be linux-ti-omap4
Jun 29 12:05:18 <lag> ogra: More than likely
Jun 29 12:05:42 <lag> ogra: I didn't know that exists
Jun 29 12:05:56 <ogra> since june 18th
Jun 29 12:06:39 <sebjan> lag: yes, Mythri is a colleague from TI
Jun 29 12:07:09 <lag> He commented out the shutdown code
Jun 29 12:07:42 <lag> I believe this was a slap-dash method to get HDMI working, but it has problems
Jun 29 12:08:33 <lag> If an HDMI device is plugged in, but not switched on the console is flooded and the system becomes inoperable
Jun 29 12:10:30 <ogra> hmm, did OOo actually just finish on the buildd or did it just fail
Jun 29 12:10:45 * ogra notices it just vanished from https://edge.launchpad.net/builders
Jun 29 12:11:00 <lag> What do you think sebjan?
Jun 29 12:11:04 <sebjan> lag: right, this is what I understand from the bug description
Jun 29 12:11:14 <lag> Correct
Jun 29 12:11:38 <lag> So, would you like me to fix it, or should I contact your colleague?
Jun 29 12:12:28 <sebjan> lag: the best would be to discuss with my colleague. I will get in touch with him and then come back to you.
Jun 29 12:12:41 <lag> Great, thanks
Jun 29 12:12:53 <ogra> aha, OOo failed due to openjdk issues
Jun 29 12:19:32 <hrw> hi robclark
Jun 29 12:19:44 <robclark> gm hrw
Jun 29 12:20:01 * robclark needs coffee
Jun 29 13:37:59 <sebjan> ogra: Hi! I am looking at your u-boot-omap4 package, and am wondering how to generate various u-boot binaries from this package (corresponding to various config files for example)? Is there a nice way to do that?
Jun 29 13:38:21 <ogra> no, saldy all ways to do that are ugly
Jun 29 13:38:50 <ogra> i will add bits and pieces to build the 3630sdp u-boot after the alpha2 release
Jun 29 13:39:23 <ogra> you will have to do multiple build runs to clean and reconfigure the environment
Jun 29 13:39:35 <ogra> its pretty complex
Jun 29 13:41:01 <berco> Is it recommended for debian packages under Ubuntu to comply with source format 3.0? http://wiki.debian.org/Projects/DebSrc3.0
Jun 29 13:41:37 <directhex> berco, depends on how easily you want to backport them, and not really an ARM question
Jun 29 13:42:39 <sebjan> ogra: ok... then I was thinking of making a different rules file, which run succesively (clean / configure / make / cp binary). That's not clean, but would be working, right? (I do not plan to release this package)
Jun 29 13:43:04 <ogra> sebjan, that would work, but its gross :)
Jun 29 13:43:21 <sebjan> ogra: or would there be another approach, not too complex that would make it also?
Jun 29 13:43:43 <ogra> i dont know one, you will definately need multiple runs
Jun 29 13:43:47 <berco> directhex: i'm packaging for arm platform. Original software was not using any packaging. So this is the first debianization of the source code
Jun 29 13:43:56 <ogra> the qemu-kvm package might be an example to steal from
Jun 29 13:44:48 <ogra> berco, up to you, really, i rarely use 3.0 for me new packages ... its definately not mandatory to use 3.0 format
Jun 29 13:45:27 <berco> ogra: thanks. I raise this question as lintian was complaining about 1.0
Jun 29 13:47:08 <ogra> why was it doing that ?
Jun 29 13:47:24 <ogra> i.e. where did you define 1.0 ?
Jun 29 13:47:56 <berco> ogra: i didn't define 1.0. I think it was just reported as a warning
Jun 29 13:48:02 <ogra> weird
Jun 29 13:48:13 * ogra has never seen such a warning
Jun 29 13:48:14 <berco> 1.0 is used by default whne no debian/source/format file
Jun 29 13:49:09 <directhex> the warning is because the default may change in the future
Jun 29 13:49:19 <directhex> so explicitly saying 1.0 prevents unexpected surprises
Jun 29 13:50:03 <ogra> oh, so you got "missing-debian-source-format", not that 1.0 is wrong
Jun 29 13:50:22 <berco> yes
Jun 29 13:50:41 <berco> plus some message about I should use 3.0 instead
Jun 29 13:51:43 <ogra> well, the warning will go away if you "mkdir -p debian/source && echo '1.0' > debian/source/format"
Jun 29 13:52:05 <ogra> it will change at some point, but not now
Jun 29 13:52:17 <ogra> no need to worry about it for the moment
Jun 29 13:52:51 <berco> ogra: thanks for the recommandation. As with 3.0 no more .diff file is generated. Instead it is a patch file
Jun 29 13:53:11 <ogra> yeah
Jun 29 14:01:30 <gsnedders> So trying to cross-compile with enviroment mainly built with apt-cross, I have a build script that wants to use sdl-config, which doesn't exist there. Any idea what to do?
Jun 29 14:01:55 <hrw> apt-cross libsdl-dev?
Jun 29 14:02:05 <gsnedders> hrw: That doesn't give sdl-config
Jun 29 14:02:16 <hrw> ah.. dpkg-cross drops it
Jun 29 14:02:23 <gsnedders> Indeed
Jun 29 14:03:24 <hrw> gsnedders: does not sdl support pkg-config?
Jun 29 14:04:35 <gsnedders> Ah, it does
Jun 29 14:05:31 <gsnedders> That'll work, thanks
Jun 29 14:36:33 <lag> sebjan: Did you have any luck in speaking with Mythri?
Jun 29 14:37:56 <sebjan> lag: yes, he shall be contacting you soon
Jun 29 14:38:30 <lag> Brilliant, thanks for you help sebjan
Jun 29 14:38:45 <sebjan> lag: np
Jun 29 14:55:11 <sumitsemwal> sebjan: lag: Mythri is a lady-colleague from TI.. :)
Jun 29 14:56:25 <sebjan> sumitsemwal: oups, I just had email contact so far... Thanks for correcting :)
Jun 29 14:56:27 <lag> sumitsemwal: I haven't said anything to the contrary
Jun 29 14:56:36 <lag> :)
Jun 29 14:57:57 <sumitsemwal> sebjan: np :) - difficult to make out with our names.
Jun 29 14:58:09 <sumitsemwal> lag: ofcourse - it was just fyi :P
Jun 29 14:59:27 <lag> :D
Jun 29 15:12:02 <ndec> mpoirier: hi
Jun 29 15:23:57 <mpoirier> ndec: sorry I didn't see you ping.
Jun 29 15:25:36 <ndec> mpoirier: no pb.
Jun 29 15:26:16 <ndec> mpoirier: so what do you want to discuss?
Jun 29 15:27:00 <mpoirier> why did your team selected to load syslink in upstart rather than "/etc/modules"
Jun 29 15:27:23 <ndec> mpoirier: we didn't decide anythin yet...
Jun 29 15:27:36 <ndec> mpoirier: i asked you the question to know what the right approach should be
Jun 29 15:27:52 <ndec> mpoirier: and you mentioned that kernel had some automatic way to do that.
Jun 29 15:28:06 <mpoirier> ndec: ok... but how did upstart got entangled in this then ?
Jun 29 15:28:37 <ndec> ndec: because i thought it would do the job since i could make a script that would run right after boot
Jun 29 15:29:12 <mpoirier> ndec: I understand.
Jun 29 15:29:46 <ndec> mpoirier: so what do you propose? you mentioned a way to get an event from kernel? i am not sure i understand what you meant.
Jun 29 15:30:12 <mpoirier> ndec: I was under the impression that your team had some temporary solution and was looking for the right way of doing this.
Jun 29 15:30:53 <ndec> mpoirier: right now, our driver is built statically in the kernel, but this will change, this is why we need that.
Jun 29 15:31:07 <mpoirier> ndec: the problem is to insert the module when the system boots.
Jun 29 15:31:18 <ndec> mpoirier: yes
Jun 29 15:31:25 <mpoirier> /etc/modules is generally how to do this.
Jun 29 15:31:52 <mpoirier> from there, inserting the module  will generate uevent, which udev is listening for.
Jun 29 15:31:54 <ndec> mpoirier: is that okay if I modify /etc/modules from a package?
Jun 29 15:32:20 <mpoirier> good question - I will look in to that.
Jun 29 15:32:31 <mpoirier> this is exactly why I wanted to have a live conversation with you.
Jun 29 15:32:57 <mpoirier> once the module is installed, do you need to kick applications ?
Jun 29 15:33:17 <mpoirier> deamon or some other program ?
Jun 29 15:33:18 <ndec> mpoirier: potentially yes
Jun 29 15:33:26 <mpoirier> ok.
Jun 29 15:33:37 <mpoirier> we can do that with udev rules.
Jun 29 15:33:44 <mpoirier> most rules already do that anyway.
Jun 29 15:34:55 <mpoirier> I will look into  modifying /etc/modules froma package and will get back to you.
Jun 29 15:35:17 <mpoirier> if we can, we have a solution.
Jun 29 15:35:17 <ndec> mpoirier: ok. thx
Jun 29 15:35:23 <mpoirier> otherwise I' keep looking.
Jun 29 15:37:11 <sebjan> mpoirier: for my understanding, there is an init script doing some modprobes on the modules listed into /etc/modules?
Jun 29 15:38:05 <lool> Yes, but this aint terribly good
Jun 29 15:38:32 <lool> The better interface is udev events, especially if this is some kind of bus or device interface or device
Jun 29 15:39:12 <lool> For instance, the ACPI BIOS parser will emit events for the various ACPI devices found with codenames and udev translates that to inserting the proper modules
Jun 29 15:39:49 <ndec> lool: in this specific case it's a device on the platform bus.
Jun 29 15:39:58 <lool> That also allows triggering extra things when e.g. a new bus or a new device shows up, so if you syslink needs to be scanned from userspace, that might be a better solution
Jun 29 15:40:07 <lool> ndec: Do you have a way to detect that device?
Jun 29 15:40:29 <ndec> lool: well, it's embedded in OMAP4, so it's always there
Jun 29 15:40:30 <mpoirier> lool: that is what I'm after...
Jun 29 15:40:55 <mpoirier> lool: do you think we could put it in the platform devices ?
Jun 29 15:40:57 <lool> Hmm if it's always there, why would people want to build it as a module?
Jun 29 15:41:12 <lool> mpoirier: That seems sensible
Jun 29 15:41:17 <ndec> lool: because it's always there on OMAP4, not OMAP3
Jun 29 15:41:33 <lool> ndec: always there on OMAP4 and never there on OMAP3?
Jun 29 15:41:47 <ndec> lool: yes
Jun 29 15:41:52 <lool> platform device might make sense indeed
Jun 29 15:42:51 <ndec> lool: it is a platform device already in the kernel. is there an api in kernel we can use to generate those events?
Jun 29 15:43:03 <lool> I dont know
Jun 29 15:45:29 <ndec> lool: mpoirier: sebjan: http://www.linuxtopia.org/online_books/opensuse_guides/opensuse11.1_reference_guide/sec_udev_kernel.html in fact it looks like the events are generated automatically by the kernel. if I look at /var/log/udev I can see them
Jun 29 15:46:34 <mpoirier> lool: I only used platform devices with statically linked drivers - have you experienced with modules ?
Jun 29 15:46:59 <lool> ndec: If you're looking at creating your own udev events, I think it's the uevent API, thinks like uevent_foo add_uevent_var() and such
Jun 29 15:47:04 <ndec> mpoirier: see above. looks like the udev event is generated automaticlly
Jun 29 15:47:37 <lool> I'm just a kernel fanboy, I'm afraid I'm not an authoritative source for anything
Jun 29 15:48:35 <mpoirier> ndec: I will look at your link...
Jun 29 16:01:57 <tgardner> ndec, davidm asked me to talk to you about module loading. Have you had your questions answered ?
Jun 29 16:02:20 <ndec> tgardner: hi. we were just discussing about this with mpoirier
Jun 29 16:02:44 <ndec> tgardner: currently it's still not answered.
Jun 29 16:03:12 <tgardner> ndec, I understand that you want to have a video device module loaded. Is it a probable device?
Jun 29 16:03:32 <ndec> tgardner: i have a platform device on my h/w (OMAP4), and I want to build the driver for it as a module, and I want the module to be loaded at boot time.
Jun 29 16:03:33 <tgardner> i.e., does it have a discoverable device ID?
Jun 29 16:04:23 <ndec> tgardner: can you confirm if udev events are generated when calling platform_device_add from the kernel?
Jun 29 16:04:53 <ndec> tgardner: I don't know for the discoverable device ID. it's something embedded in OMAP4.
Jun 29 16:05:22 <tgardner> ndec, well, the simplest thing to do is to add the module name to /etc/modules, then run update-initramfs
Jun 29 16:05:35 <tgardner> it'll get loaded on the next boot cycle
Jun 29 16:05:50 <ndec> tgardner: but I thought it would not be eleguant to update /etc/modules from a package.
Jun 29 16:05:56 <ogra> tgardner, can you also provide a proper solution from the kernel ? :)
Jun 29 16:06:12 <tgardner> ograonly if its a discoverable device
Jun 29 16:06:18 <tgardner> ogra^^
Jun 29 16:06:38 <ogra> isnt there some function that walks devices that can be used ?
Jun 29 16:07:14 <ogra> how is that normally done on non PCI systems ?
Jun 29 16:07:17 <davidm> ogra, only if the device is discoverable
Jun 29 16:07:24 <tgardner> given that this is ARM, its probably just a well known memory area. This is the issue that the device map stuff is attempting to solve.
Jun 29 16:08:17 <tgardner> ogra: when the PCI platform driver is loaded it grovels the PCI bus, sending discover events to udev
Jun 29 16:08:17 <ndec> tgardner: when is the udev event generated? right now I have the module built in statically in my kernel, and I can see udev event at boot time for it.
Jun 29 16:08:42 <ogra> tgardner, right, i was hoping there is something similar for the platform bus
Jun 29 16:08:49 <ndec> b
Jun 29 16:09:04 <tgardner> ndec, ogra: so, is this a platform driver, or a simple driver?
Jun 29 16:09:14 <ogra> platform i think
Jun 29 16:09:17 <ndec> tgardner: platform driver
Jun 29 16:09:40 <tgardner> ndec, then I assume your platform driver is initiating the udev event?
Jun 29 16:09:48 <tgardner> (when its built in)
Jun 29 16:10:10 <ndec> tgardner: i guess so, but i don't know how it's being generated.
Jun 29 16:10:45 <ndec> tgardner: I am calling platform_device_add() and then platform_driver_register()
Jun 29 16:10:58 <ogra> either will generate the event
Jun 29 16:11:08 <ogra> s/either/one of them/
Jun 29 16:12:00 <tgardner> ndec, so its a chicken and egg problem. its the platform driver that emits discovery events, right? so how does the platform driver get loaded? Usually they are built-in, but in this case it _must_ be a  module, right?
Jun 29 16:12:28 <mpoirier> tgardner: and this is what I'm trying to find...
Jun 29 16:12:43 <tgardner> ok, then the solution is to add it to /etc/modules
Jun 29 16:12:45 <mpoirier> if platform drivers can work with  loadable modules.
Jun 29 16:13:13 <tgardner> ogra: is /etc/modules considered a conf file wrt to debian policy?
Jun 29 16:13:33 <ogra> i dont think so
Jun 29 16:13:37 <ndec> tgardner: don't think so. there are 2 separate things: the platform device and the platform driver. my feeling is that the udev event is made then the platform device is added. so this is call must be in the kernel at boot. but the platform driver registration can be in the module
Jun 29 16:13:51 <ogra> its also no prob to modify it from our first boot tool in the images
Jun 29 16:14:30 <ogra> it just doesnt feel right at all
Jun 29 16:15:06 <tgardner> ogra, well, the _right_ thing to do is to build the dang thing into the kernel, but that doesn't seem to be a choice.
Jun 29 16:15:37 <ogra> or make the HW discoverable by the kernel somehow
Jun 29 16:15:53 <ogra> so it can be loaded dynamically
Jun 29 16:15:55 <ndec> tgardner: that would then mean that if we have a generic ARM kernel, it would need to have all platform drivers... that looks wrong to me.
Jun 29 16:16:06 <tgardner> ndec, have you tried building these drivers as modules, then modprobe them sometime after boot to see if they do what you expect?
Jun 29 16:16:32 <ndec> tgardner: no
Jun 29 16:16:47 <ogra> tgardner, the fec NIC driver on the imx51 platform was a platform driver iirc
Jun 29 16:16:54 <ogra> that used to work fine
Jun 29 16:17:02 <ogra> and was dynamically loaded
Jun 29 16:17:07 <tgardner> ogra: I thought that was a simple ethernet driver
Jun 29 16:17:11 <ogra> yes
Jun 29 16:17:19 <ogra> but hooked into the platform bus
Jun 29 16:17:36 <ogra> we had to patch NM to accept platform devices to make it work at all
Jun 29 16:18:11 <tgardner> where is the source for this stuff?
Jun 29 16:18:19 <ogra> so i wonder if what worked there might be applicable to ndec's case
Jun 29 16:18:24 <ogra> should be in our imx51 tree
Jun 29 16:18:27 <tgardner> not the FEC, but the other platform driver
Jun 29 16:18:40 <ogra> oh, the OMAP4 one ?
Jun 29 16:18:44 <tgardner> yeah
Jun 29 16:18:49 <ogra> not sure thats in our kernel tree already
Jun 29 16:18:57 <ogra> but if so, its in the omap4 tree
Jun 29 16:19:04 <ogra> ndec should be able to tell
Jun 29 16:19:05 <tgardner> unless it was part of Bryan's pull request
Jun 29 16:19:10 <ndec> tgardner: in the omap4 branch. in the ubuntu kernel. in drivers/dsp/syslink
Jun 29 16:19:22 <tgardner> ndec, cool, lemme take a look
Jun 29 16:22:27 <Hellwarrior> HI
Jun 29 16:22:51 <Hellwarrior> hey anyone in here familiar with the i.mx31
Jun 29 16:24:16 <davidm> Hellwarrior, we don't support the iMX31, it is not an ARMv7 sorry
Jun 29 16:24:35 <Hellwarrior> oh would you know where I can go to ask??
Jun 29 16:25:33 <GrueMaster> Hellwarrior: I believe debian would work with it.  check their channels.
Jun 29 16:26:25 <Hellwarrior> okay
Jun 29 16:26:37 <davidm> That was my thought too
Jun 29 16:26:55 <GrueMaster> I know the chumby is based on that proc.
Jun 29 16:27:11 <davidm> I "think" it's an ARMv5 or v6 but not sure, just know for sure it's not a v7
Jun 29 16:27:29 <Hellwarrior> just basically I am trying to open up a bin file to view its contents with no luck I ran it thru a tool I found on the freescale site and it spit it out a .s19 file
Jun 29 16:27:37 <Hellwarrior> not sure where to go from there
Jun 29 16:28:10 <Hellwarrior> actually I think it runs an arm 11 core
Jun 29 16:29:45 <Hellwarrior> basically I took a .bin update file a converted it into that s19 file but not sure how to view its contents
Jun 29 16:38:53 <davidm> ARm 11 core would be ARMv6 then
Jun 29 16:42:52 <davidm> Sorry I don't know anything about .s19 files
Jun 29 17:22:31 <cwillu_at_work> rcn-ee, was out of the office last week;  thanks for looking into that though
Jun 29 17:23:00 * cwillu_at_work looks forward to the latest shiny kernel
Jun 29 19:26:39 <ogra_cmpc> NCommander, ===== Downloading preinstalled filesystem images =====
Jun 29 19:26:40 <ogra_cmpc> Tue Jun 29 20:23:29 BST 2010
Jun 29 19:26:40 <ogra_cmpc> http://acorn.buildd/~buildd/LiveCD/maverick/ubuntu-netbook-omap/current/livecd.ubuntu-netbook.ext3:
Jun 29 19:26:40 <ogra_cmpc> 20:23:29 ERROR 404: Not Found.
Jun 29 19:32:06 <tgardner> ndec, mpoirier: I sent some patches to Bryan Wu that modularize the syslink drivers. Lets see what he thinks about it.
Jun 29 19:33:16 <mpoirier> tgardner: do you see any problem with a package modifying /etc/modules ?
Jun 29 19:33:45 <tgardner> mpoirier, dunno, I gotta look up policy on that.
Jun 29 19:34:12 <lool> mpoirier: It would seem you have less risky alternatives before going to that, like adding a new upstart job which loads your module
Jun 29 19:34:13 <tgardner> mpoirier, I'm pretty sure its part of initramfs-tools
Jun 29 19:34:49 <lool> tgardner: module-init-tools.postinst seems to create it here
Jun 29 19:35:03 <tgardner> lool, ah, thats the place
Jun 29 19:35:34 <ogra_cmpc> as i said, its no prob to modify it
Jun 29 19:35:43 <ogra_cmpc> we can do that on first boot of the image
Jun 29 19:35:44 <tgardner> lool, I'll let Bryan figure it out since he has the HW
Jun 29 19:35:55 <ogra_cmpc> tgardner, he doesnt
Jun 29 19:35:57 <lool> I personally tend of think of it as an user configuration file and would keep away from touching it automatically; I suppose you could technically arrange to add stuff to it, but that doesn't seem terribly nice
Jun 29 19:37:10 <ogra_cmpc> lool, we did that before for psaux or lp modules
Jun 29 19:37:26 <ogra_cmpc> i dont see a prob with adding stuff to it before a user can even touch it
Jun 29 19:38:07 <lool> fuse-utils does something along the lines of adding stuff to /etc/modules
Jun 29 19:38:22 <lool> It poses challenges such as actually allowing an user to disable that behavior (disabling the module loading)
Jun 29 19:38:23 <ogra_cmpc> not anymore since jaunty or so
Jun 29 19:39:05 <ogra_cmpc> as you said, its a user config file, so a user can remove the line we add
Jun 29 19:39:29 <lool> I really recomment a trivial upstart job instead myself, but it seems we're only discussing workarounds when the fix to emit an event and process it from the kernel is already known
Jun 29 19:39:41 <ogra_cmpc> right
Jun 29 19:39:47 <lool> ogra_cmpc: The package has to be careful to honor that when its upgraded though
Jun 29 19:39:50 <lool> anyway
Jun 29 19:39:51 * lool => &
Jun 29 19:40:02 <ogra_cmpc> lool, no package involved, jasper can do it
Jun 29 19:40:25 <ogra_cmpc> thats the reason we have it :)
Jun 29 20:08:19 * ogra_cmpc is desparate
Jun 29 20:33:36 <armin76> ogra_cmpc: mariachi? :D
Jun 29 22:44:42 <rcn-ee> cwillu_at_work, what you went on a vacation? ;)
Jun 30 00:58:14 <cwillu> rcn-ee, kinda sorta :p
Jun 30 00:58:56 * ogra_cmpc is surprised to see that cwillu actually uses that non-work nick 
Jun 30 00:59:09 <ogra_cmpc> i always thought thats only channel decoration :)
Jun 30 00:59:13 <cwillu> heh
Jun 30 00:59:37 <cwillu> I don't usually have any arm equipment to hack on here :p
Jun 30 01:00:17 * prpplague pokes ogra and ogra_cmpc to see if they are alive
Jun 30 01:00:25 <ogra_cmpc> barely
Jun 30 01:00:44 <ogra_cmpc> working since 7am (its 3am now) ... and nearly falling over
Jun 30 01:00:48 <prpplague> ogra_cmpc: ubuntu arm with multiple frame buffers
Jun 30 01:00:57 <prpplague> ogra_cmpc: i'll make it quick
Jun 30 01:01:21 <ogra_cmpc> sounds intresting, do you think X is capable of managing them properly ?
Jun 30 01:01:37 <prpplague> well i know X is, just not sure how
Jun 30 01:01:45 * prpplague isn't a userland person
Jun 30 01:02:03 <ogra_cmpc> will likely need changes to the xserver
Jun 30 01:02:08 <prpplague> hmm
Jun 30 01:02:26 <ogra_cmpc> the current omapfb one we have even hardcodes fb0
Jun 30 01:02:36 <prpplague> OH
Jun 30 01:02:57 <ogra_cmpc> there is big room for improvement :)
Jun 30 01:03:08 <prpplague> we need to start discussing it now
Jun 30 01:03:25 <prpplague> (or when more correctly when you've had some rest)
Jun 30 01:03:50 <prpplague> are you going to be working with the blaze and/or panda?
Jun 30 01:03:55 <ogra_cmpc> prpplague, at a time when XorA is around, he is upstream for the omapfb xserver
Jun 30 01:04:06 <prpplague> OH
Jun 30 01:04:12 <ogra_cmpc> i work with both, yes
Jun 30 01:04:32 * prpplague can deal with XorA hehe
Jun 30 01:04:37 <ogra_cmpc> heh
Jun 30 01:05:04 <prpplague> ogra_cmpc: we need to setup a time with XorA within the next 7 days to discuss the matter
Jun 30 01:05:05 <ogra_cmpc> i havent tried omapfb on the panda yet though
Jun 30 01:05:33 <prpplague> ogra_cmpc: i have ubuntu running on one fb at a time right now
Jun 30 01:05:36 <ogra_cmpc> i seem to be one of the lucky guys that have a HDMI monitor the panda can actually handle
Jun 30 01:05:38 <prpplague> ogra_cmpc: but not both
Jun 30 01:06:03 <ogra_cmpc> they seem to be rare atm, some issues wiht reading EDID data
Jun 30 01:06:03 <prpplague> ogra_cmpc: thats odd, we've not found one that doesn't work
Jun 30 01:06:24 <ogra_cmpc> intresting
Jun 30 01:06:40 <prpplague> ogra_cmpc: we need to get sync'd up on this so i can resolve those issues
Jun 30 01:06:45 <cwillu> prpplague, does maverick's omapfb support xorg's -nr yet?
Jun 30 01:06:51 <ogra_cmpc> well, mine works too, even though i was told samsung would be the most problematic and i have a samsung
Jun 30 01:06:56 <cwillu> i.e., plymouth slickness
Jun 30 01:06:59 <cwillu> it's a trivial patch if not
Jun 30 01:07:13 <ogra_cmpc> cwillu, you didnt file a bug and patch yet ;)
Jun 30 01:07:16 <prpplague> cwillu sorry don't know, i'm normally a kernel/boardbringup guy
Jun 30 01:07:33 <ogra_cmpc> cwillu, file me a bug and i'll upload the fix
Jun 30 01:07:49 <ogra_cmpc> feel free to even assign it to me
Jun 30 01:07:54 <prpplague> ogra_cmpc: now, is your display actually hdmi or is it dvi-d?
Jun 30 01:08:01 <ogra_cmpc> HDMI
Jun 30 01:08:07 <cwillu> I think I have a debdiff
Jun 30 01:08:13 <ogra_cmpc> the DVI port isnt working yet i was told
Jun 30 01:08:18 <cwillu> whether it's actually sane is another matter
Jun 30 01:08:25 <prpplague> ogra_cmpc: dvi is working but has some timing issues
Jun 30 01:08:26 <ogra_cmpc> so i didnt bother to try
Jun 30 01:08:38 <ogra_cmpc> ah, i was told differently
Jun 30 01:08:42 <prpplague> ogra_cmpc: you can actually use the HDMI port to connect to a dvi-d display as well
Jun 30 01:08:49 <ogra_cmpc> indeed
Jun 30 01:09:13 <prpplague> ogra_cmpc: for instances you can mix and match dvi-d and hdmi, you can have 2 hdmi, 2 dvi or 1 dvi and 1 hdmi
Jun 30 01:09:21 <ogra_cmpc> but i'm using the DVI port for the beagle, so having the panda on HDMI is very convenient
Jun 30 01:09:43 <ogra_cmpc> (and my main machine onj VGA)
Jun 30 01:09:59 <ogra_cmpc> saves a lot of space ;)
Jun 30 01:09:59 <prpplague> ogra_cmpc: right np
Jun 30 01:10:16 <prpplague> ogra_cmpc: i actually prefer using dvi-d devices myself
Jun 30 01:10:19 <ogra_cmpc> inded i can switch plugs around for testing
Jun 30 01:10:34 <prpplague> ogra_cmpc: anyway, when is the best time to contact you via irc to debug some of this?
Jun 30 01:10:50 <ogra_cmpc> european business hours usually
Jun 30 01:10:54 <cwillu> ogra_cmpc, okay, I'll ping you tomorrow from _at_work :p
Jun 30 01:11:06 <prpplague> ogra_cmpc: ahh, ok
Jun 30 01:11:14 <ogra_cmpc> i'm normally up after 9/10 UTC
Jun 30 01:11:26 <prpplague> ogra_cmpc: i'll try to get with you tomorrow and set down some times we can iron out a plan of support
Jun 30 01:11:44 <ogra_cmpc> great
Jun 30 01:11:55 * prpplague hands ogra_cmpc some nice belgian ale and sends ogra_cmpc to bed
Jun 30 01:12:07 <ogra_cmpc> *slurp*
Jun 30 01:12:10 <ogra_cmpc> :)
Jun 30 01:12:43 <prpplague> wait the belgian was for me, i was suppose to give you some coors
Jun 30 01:12:49 <ogra_cmpc> lol
Jun 30 01:12:52 * prpplague jokes with ogra_cmpc 
Jun 30 01:13:06 * ogra_cmpc gets a pilsner urquell from the fridge then :P
Jun 30 01:13:32 <prpplague> hehe decent choice
Jun 30 01:13:46 * prpplague drinks his duvel
Jun 30 01:14:21 <ogra_cmpc> while i'm german i'm a big fan of check beers
Jun 30 01:14:37 * ogra_cmpc looks forward to be in prague in a few weeks :)
Jun 30 01:14:52 <prpplague> ogra_cmpc: dont suppose you are headed to CELF-EU ?
Jun 30 01:15:06 <ogra_cmpc> is it in prague this time ?
Jun 30 01:15:19 <prpplague> cambridge
Jun 30 01:15:26 * ogra_cmpc is going to the ubuntu distro sprint ... doing face to face work 
Jun 30 01:15:37 <ogra_cmpc> when is it ?
Jun 30 01:15:46 <prpplague> october
Jun 30 01:16:05 <ogra_cmpc> if it doesnt clash with any ubuntu dates i might go
Jun 30 01:16:21 <prpplague> http://www.embeddedlinuxconference.com/elc_europe10/index.html
Jun 30 01:16:24 <ogra_cmpc> we're releasing on the tenth this time
Jun 30 01:16:49 <ogra_cmpc> 27 and 28
Jun 30 01:16:51 <ogra_cmpc> sounds good
Jun 30 01:17:02 <prpplague> i'm hoping i'll get a trip to Nice from TI sometime soon, but i have to do some major work
Jun 30 01:17:19 <ogra_cmpc> Nice is nice :)
Jun 30 01:17:31 <ogra_cmpc> though its probably way to warm now
Jun 30 01:17:59 <prpplague> ogra_cmpc: hehe, just an excuse to  visit some of belgian abbeys
Jun 30 01:18:05 <ogra_cmpc> heh
Jun 30 01:18:38 * prpplague goes to read schematics
Jun 30 01:18:46 <prpplague> later
Jun 30 01:18:51 <ogra_cmpc> night then
Jun 30 01:19:02 * ogra_cmpc will go to bed after the beer
**** ENDING LOGGING AT Wed Jun 30 02:59:57 2010