| === BV1AL_ is now known as BV1AL | ||
| === Guest5922 is now known as panda|x201 | ||
| infinity | robclark: You around? | 04:18 |
|---|---|---|
| robclark | hey infinity | 04:24 |
| infinity | Yo. | 04:24 |
| infinity | Do you know if all the pieces are in place in quantal for us to violently remove the -omapfb X driver, and have -omap magically work? | 04:25 |
| robclark | mostly.. I think rsalveti was working on making xorg autodetect the right driver | 04:25 |
| infinity | Autodetection wouldn't be necessary if omapfb wasn't on disk, right? :) | 04:26 |
| rsalveti | you can already remove omapfb | 04:26 |
| rsalveti | but -omap is still not working automatically | 04:26 |
| robclark | but other than the need for a .conf file, it should be all good | 04:26 |
| infinity | rsalveti: So, removing omapfb right now just falls back to fbdev? | 04:26 |
| rsalveti | infinity: it was never using omapfb | 04:27 |
| infinity | rsalveti: seriously? | 04:27 |
| rsalveti | no, by default it was using fbdev afaik, and the proprietary omap one if you had the sgx driver installed | 04:28 |
| infinity | So, omapfb was just lame code that we never executed, despite shipping? Go us. | 04:29 |
| rsalveti | infinity: it could be used, I believe folks using beagle were using it in the past | 04:30 |
| infinity | rsalveti: "could be used" isn't the same as "loaded by default", which is what I meant by "never executed". | 04:30 |
| rsalveti | it was never used for panda | 04:31 |
| rsalveti | and I believe for beagle as well, once we switched for the drm driver | 04:31 |
| rsalveti | which iirc happened at the previous cycle already | 04:31 |
| robclark | I suppose it doesn't hurt to have.. beagle folks could always add a xorg.conf | 04:31 |
| infinity | I assume the goal for -omap is to actually *use* it in an automagic fashion on all OMAP[2345]* SoCs? | 04:31 |
| rsalveti | infinity: yup | 04:31 |
| infinity | \o/ | 04:32 |
| rsalveti | and that's what I'm currently trying to do | 04:32 |
| robclark | omapfb would probably be a bit better performance (despite no xrandr) if you don't have pvr libs | 04:32 |
| infinity | robclark: Having working kms is such a massive win that I doubt anyone will care about marginally slower 2D draws. | 04:32 |
| infinity | robclark: Assuming it is only marginal. | 04:32 |
| scientes_ | dms=awesomesause | 04:33 |
| scientes_ | *kms | 04:33 |
| robclark | well.. I need to add support for cached buffers when you don't have pvr.. that will minimalize the perf difference | 04:33 |
| robclark | but I haven't had time to do that yet | 04:33 |
| scientes_ | drkms ;) | 04:33 |
| rsalveti | so I'd vote in favor of improving the -omap driver for all omap socs | 04:34 |
| rsalveti | first getting it to work automatically, then improving it | 04:34 |
| rsalveti | and getting sgx to work on the panda case | 04:34 |
| rsalveti | if maintaining -omapfb is a pain | 04:34 |
| robclark | yup | 04:37 |
| rsalveti | robclark: also, for plymouth, this is what is already done at upstream: http://cgit.freedesktop.org/plymouth/commit/?id=527400dc5a9da4cd3ef8a831e7309e1627d6b3b0 | 04:39 |
| rsalveti | they also removed the parts specific for radeon and nouveau | 04:39 |
| rsalveti | I'm checking if this patch would be enough in our case already, but it's now finally using a generic solution for all use cases | 04:39 |
| * robclark expects that should work | 04:40 | |
| rsalveti | robclark: yup, worked fine | 06:30 |
| === dduffey_afk is now known as dduffey | ||
| ogra_ | rsalveti, you rock !!! | 07:52 |
| ogra_ | sadly now that we have a splash we wont have a desktop anymore | 07:53 |
| ogra_ | (unity-2d was dropped yesterday) | 07:53 |
| TheMuso | ogra_: And if my tests with LLVM Pipe on an x86 machine with fbdev on an NVIDIA card that is not supported by nouveau yet are anything to go by, LLVM pipe on arm will be *VERY* painful. | 08:21 |
| TheMuso | Actually thats something I should test tomorrow. Remove the pvr driver and see how bad things are. | 08:23 |
| TheMuso | Meh screw tomorrow, lets try now. :) | 08:23 |
| ogra_ | TheMuso, LLVM pipe on arm is nonexisting yet | 08:26 |
| ogra_ | i mean there is *something* but thats far from usable | 08:26 |
| ogra_ | alpha state at most | 08:26 |
| TheMuso | Ah ok. | 08:27 |
| TheMuso | Well even on X86 IMO its really poor. | 08:27 |
| TheMuso | I can't believe we even want to consider putting that into users hands. Sure its not an LTS, but its a release.. | 08:28 |
| ogra_ | yep, you need a powerful machine | 08:28 |
| suihkulo1ki | https://blogs.oracle.com/henrik/entry/oracle_releases_jdk_for_linux | 08:53 |
| suihkulo1ki | softfloat abi still, but I guess installable using multiarch? | 08:54 |
| marvin24 | ogra_: did you tried unity-3d with the tegra drivers on quantal? | 08:59 |
| ogra_ | marvin24, not yet, i suppose i should before the 13 abi becomes the default | 09:01 |
| marvin24 | I always thought unity works fine on omap ... | 09:02 |
| ogra_ | if you have working drivers it does | 09:10 |
| * ogra_ tries an ubuntu-desktop install in a qemu beagle VM for laughs | 09:31 | |
| jonjo | hi | 10:03 |
| jonjo | can anyone help me with PowerVR SGX? | 10:04 |
| sveinse | jonjo: More specifically? | 10:05 |
| jonjo | I am trying to get OpenGL ES working with x11 | 10:05 |
| jonjo | I am using the samsung s5pv210 core | 10:05 |
| sveinse | jonjo: Sorry, no experience with x11 in this context | 10:06 |
| sveinse | Are there any particular reasons which requires kernel >=3.0 in precise (armel), or can it run fine on say 2.6.37 ? | 11:28 |
| ogra_ | udev migth need features from newer kernels | 11:47 |
| ikke-t | hi, i'm failing setting pandaboard to boot over nfs. anyone able to help? | 11:47 |
| ikke-t | it get's stuck at the time it should mount the nfs, kernel is up | 11:47 |
| sveinse | ogra_, might? Where can I learn better what might is? | 11:48 |
| ikke-t | this is the last output on serial: | 11:48 |
| ikke-t | http://paste.ubuntu.com/1150485/ | 11:48 |
| ogra_ | dunno, udev changelog probably | 11:48 |
| ikke-t | using ubuntu precise for the exercise | 11:51 |
| ikke-t | anyone booting over nfs here? | 11:51 |
| ogra_ | did you set BOOT=nfs in your initramfs config before creating the initrd ? | 11:53 |
| ogra_ | it should theoretically *just work* | 11:53 |
| ikke-t | ogra_: yes, i did, along with netboot for module option | 11:56 |
| ikke-t | my kernel params are: | 11:57 |
| ikke-t | ro console=ttyO2,115200n8 vram=40M mem=456M@0x80000000 mem=512M@0xA0000000 elevator=noop root=/dev/nfs nfsroot=10.10.10.252:/mnt/ikraid/ikke/nfs/panda,nolock,wsize=1024,rsize=1024 rootdelay=18 ip=dhcp fixrtc netboot=nfs boot=nfs | 11:57 |
| ikke-t | anything obviously wrong there? | 11:57 |
| ogra_ | not on first glance, your paste doesnt have a rootpath though | 11:58 |
| ikke-t | that's from dhcp, targeted for pxe | 11:59 |
| ikke-t | should it contain the nfs path in dhcp answer? | 12:00 |
| ikke-t | i used that for ipxe boots | 12:00 |
| ikke-t | ogra_: the hdmi output seems to print something about the path too | 12:03 |
| ikke-t | t: need a path | 12:03 |
| ikke-t | i don't see what's before "t:", since it's out of tv borders | 12:03 |
| ikke-t | how to provide it the path? | 12:04 |
| ogra_ | you can set it in your dhcpd config | 12:04 |
| LetoThe2nd | known issues with the latest nfs-common updates on QQ? my panda always gets stuck on "gssd stop/pre-start, process 1016" | 12:04 |
| * ogra_ isnt sure about the exact wording | 12:05 | |
| ogra_ | LetoThe2nd, either that or a kernel thing | 12:05 |
| ogra_ | you could try the new 3.5 kernel if you want ;) | 12:05 |
| LetoThe2nd | ogra_: its a vanilla 3.4.7 + RT | 12:05 |
| ogra_ | people.canonical.com/~ppisati/ti-omap4-tilt-34-on-35/linux-image-3.5.0-205-omap4_3.5.0-205.10_armhf.deb | 12:05 |
| ikke-t | ah, it seems i would need dhcp option rootpath. unfortunately monowall dhcp server doesn't have that. | 12:17 |
| ppisati | ogra_: for Q/omap4, did you do something for pulseaudio? | 12:57 |
| ogra_ | what should i do for pulseaudio ? | 12:57 |
| ppisati | ogra_: i've a P/omap4 userbase + 3.4 kernel but i've no audio output | 12:57 |
| ppisati | ogra_: in the audio settings there's only a dummy output | 12:58 |
| ogra_ | yes, the device name changed somewhere along the road since precise | 12:58 |
| ppisati | ogra_: right, that thing | 12:58 |
| ppisati | ogra_: so i need to upgrade my usb disk to Q it seems... | 12:58 |
| ogra_ | we will need to update th ealsa udev rules once there is a final name | 12:58 |
| ppisati | but does it work now or not? | 12:59 |
| ogra_ | it doesnt until we fix the udev rule or the device name | 12:59 |
| ppisati | ah | 12:59 |
| ppisati | can't remember if i tested audio on the previous Q snapshots | 13:00 |
| ogra_ | i tested it and knew it was broken, but didnt bother until we have a final kernel | 13:00 |
| ogra_ | ppisati, /lib/udev/rules.d/90-alsa-ucm.rules has the device id's we match against (as shown in "cat /proc/asound/cards") | 13:01 |
| ppisati | flag@panda:~$ cat /proc/asound/cards | 13:31 |
| ppisati | 0 [PandaBoardES ]: PandaBoardES - PandaBoardES | 13:31 |
| ppisati | PandaBoardES | 13:31 |
| ppisati | flag@panda:~$ grep PandaBoardES /lib/udev/rules.d/90-alsa-ucm.rules | 13:31 |
| ppisati | ATTRS{id}=="PandaBoardES", RUN+="/usr/bin/alsaucm -c PandaBoardES set _verb HiFi" | 13:31 |
| ppisati | ATTRS{id}=="PandaBoardES", RUN+="/usr/bin/alsaucm -c PandaBoardES set _verb Record" | 13:31 |
| ppisati | ah | 13:32 |
| ppisati | could not open configuration file /usr/share/alsa/ucm/PandaBoardES/PandaBoardES.conf | 13:32 |
| ppisati | uhm | 13:32 |
| ogra_ | sounds like a bug :) | 13:34 |
| rsalveti | ogra_: hopefully we'll get the sgx stuff working before feature freeze | 13:51 |
| rsalveti | ti should be able to publish the driver based on the latest xorg abi probably tomorrow | 13:52 |
| rsalveti | it'd also be good to have the new 3.5 based kernel available at quantal as well | 13:52 |
| * ogra_ prays | 13:52 | |
| rsalveti | it works way better at my panda es | 13:52 |
| ogra_ | rsalveti, will be uploaded tomorrw | 13:52 |
| rsalveti | great | 13:53 |
| ogra_ | so should it already seed the omap xorg driver ? | 13:53 |
| ogra_ | i dont think it will do any harm, wont be auto selected anyway | 13:53 |
| rsalveti | ogra_: you can, but it'll not make any difference | 13:53 |
| ogra_ | its awesome if you add a minimal xorg.conf though | 13:54 |
| rsalveti | I'm working on trying to get the autoload/autodetect working properly | 13:54 |
| ogra_ | first time i see the monitor applet work :) | 13:54 |
| ogra_ | yep, i got that | 13:54 |
| ogra_ | even without we coudl worst case just ship it with an xorg.conf.d snippet though | 13:54 |
| rsalveti | the problem with the xorg.conf is that if it fails, it'll not load x | 13:55 |
| ogra_ | oh, ouch | 13:55 |
| rsalveti | unless we also add fbdev there, should be possible | 13:55 |
| rsalveti | but the good thing about the autoload is that it tries a bunch of drivers | 13:55 |
| rsalveti | and fbdev is always the last one, in case it all fails | 13:56 |
| ogra_ | iirc asac patched fbdev ages ago to use autoload | 13:56 |
| rsalveti | I have a solution for the omap driver already, but first want to check with upstream if that's the way to go | 13:56 |
| rsalveti | so either way we should have something for next week | 13:57 |
| ogra_ | cool | 13:57 |
| ogra_ | oh, yay, finally | 13:57 |
| rsalveti | I think the new xorg will land this week still, right? | 13:57 |
| * ogra_ fiddles with quem since a while ... i was finally able to produce a proper string that gives me an USB disk in the beaglexm emu | 13:57 | |
| rsalveti | if not done yet | 13:57 |
| ogra_ | i think they planned to move it tomorrow | 13:58 |
| === prpplague^2 is now known as prpplague | ||
| === morphis|away is now known as morphis | ||
| === gallth is now known as tgall_foo | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!