| 23:59 | jnettlet | The thing is XV was really just not created to handle zero-copy |
| 00:01 | _rmk_ | exactly, so either you don't support it, or you introduce some custom hack which will probably be implementation specific |
| 00:02 | jnettlet | almost everything in Xorg is written expecting things to first get written to system memory and then sent over the AGP or PCI bus to video ram. |
| 00:06 | dv_ | yeah, it shows |
| 00:06 | dv_ | I hope wayland does this better |
| 00:06 | setuid | How do I reset the visible X settings that lightdm uses? I changed the resolution and it accepted it, but now lightdm starts and the screen is blank. |
| 00:06 | setuid | There's signal, just nothing displayed |
| 00:07 | setuid | I can ctrl-alt-Fx, and get to a terminal, just can't get visible lightdm UI |
| 00:10 | jnettlet | _rmk_, I know you are using a custom fourcc to identify a zero copy situation. Why not just have a zero-copy XV attribute defaults to False and let the user enable it if it is applicable. |
| 00:11 | jnettlet | Or we could set up an additional XV adapter just for zero-copy |
| 00:13 | jnettle | 00:13 * jnettlet will sleep on this. |
| 00:13 | dv_ | the other question is |
| 00:13 | setuid | blarg |
| 00:13 | dv_ | how do you pass on the buffer |
| 00:14 | dv_ | assuming you use dmabuf, how do you pass the fd through Xv? |
| 00:38 | setuid | How do I change the boot resolution, or create a menu that shows up at boot, so I can choose which res I need to boot to, depending on which monitor/screen I'm connected to? |
| 04:51 | setuid | Anyone know where I can find the configured kernel source for the Ubuntu install on the CuBox? |
| 04:52 | setuid | I need to build ndiswrapper, so I can load the Windows driver for the D-Link dwl-122 wireless usb adapter I have |
| 05:07 | Coburn | setuid: Won't work. You can't run x86 Windows Driver for CuBox |
| 05:08 | Coburn | CuBox is ARM, that said driver is x86/x64 |
| 05:08 | setuid | Right, but there's claims that rt73 and/or prism2_usb will work. |
| 05:08 | setuid | rt73 doesn't recognize it, and prism2_usb no longer exists, because linux-wlan project is dead |
| 05:08 | setuid | can't find any source anywhere |
| 05:09 | setuid | but even if I could find the source, I can't build it, because there's no configured kernel source for this 3.6.9 kernel |
| 05:09 | setuid | sigh |
| 05:09 | setuid | Linux cubox 3.6.9-00797-g0d7ee41 #179 PREEMPT Tue Jun 18 20:29:40 IDT 2013 armv7l armv7l armv7l GNU/Linux |
| 09:59 | dv_ | _rmk_, jnettlet: looking at the marvell code, I am skeptical if it is possible to associate a dma buffer used by GAL with a pixmap in an application |
| 09:59 | dv_ | the driver puts the logical address in the devPrivate field of the pixmap, but for applications, pixmap is an opaque object |
| 10:00 | dv_ | I'm still looking if there is a cleaner way to associate a pixmap with a user-defined buffer |
| 10:04 | jnettlet | dv_, sorry I forgot you were my timezone. I was poking at this when I woke up and think this is what you want to use. gst_x_overlay_set_window_handle |
| 10:04 | dv_ | actually no. thats what I use for associating a gst sink with an existing window |
| 10:04 | dv_ | I am talking about associating a physical buffer with a GAL surface and an X11 pixmap |
| 10:04 | dv_ | (the pixmap being inside a window) |
| 10:05 | dv_ | the example you found is driver code, which seems to have access to more internals than applications have |
| 10:09 | dv_ | gst_x_overlay_set_window_handle is typically used to anchor the sink's own window on a parent window btw. |
| 10:11 | jnettlet | but once you have the xwindow can't you just use XSetWindowBackgroundPixmap to feed it the galcore created pixmap? |
| 10:12 | jnettlet | you just have to make sure to run XMapWindow afterwards or it won't get displayed. |
| 10:14 | jnettlet | dv_, haha...here is a gstreamer plugin that does what you are trying to do, but for an old omap processor. https://gitorious.org/gstreamer-omap/gst-plugins-bad/source/3ae89bc08319c0e9a4e2d72cbf2d332e87486420:sys/pvr2d/gstpvrvideosink.c |
| 10:15 | dv_ | yeah. powervr specific stuff. |
| 10:15 | jnettlet | and looking up that plugin reveals a couple of other plugins |
| 10:15 | dv_ | thats exactly what I wanna do, except for vivante. |
| 10:17 | jnettlet | right |
| 10:21 | jnettlet | dv_, they also made a dri2videosink that uses dmabuf |
| 10:21 | jnettlet | this must have been for the initial implementation |
| 10:24 | dv_ | oh, rob clark is the author |
| 10:24 | dv_ | but hmm |
| 10:25 | dv_ | see, if I can attach in an application a physical buffer to a pixmap, then I could also use the IPU for drawing |
| 10:25 | dv_ | OK, this is then imx speciifc |
| 10:25 | jnettlet | just but just substitute Galcore for IPU |
| 10:26 | dv_ | yeah |
| 10:26 | dv_ | the actual problem atm is this association |
| 10:26 | dv_ | once I got that, the rest is straightforward |
| 10:34 | jnettlet | can I use the dri2videosink source as an example to Vivantize it? |
| 10:34 | dv_ | not sure |
| 10:35 | dv_ | its pretty big, and full of powervr stuff |
| 10:35 | dv_ | removing that could leave only the X window parts behind, which isnt much |
| 10:39 | jnettlet | actually, all you need is the X window parts. Then you just need to take the physical buffer and create a galcore surface for it. Do the same for the Xwindow backing pixmap, then do the filterblit to convert source format to destination format and size |
| 10:40 | dv_ | why two buffers? one is enough |
| 10:40 | dv_ | but damnit, all parts I can find that associate the pixmap with the buffer seem to use EXA specific stuff |
| 10:41 | jnettlet | you don't create the buffer for the vmeta decoded frame, you just need to associate that address with a galcore surface |
| 10:41 | dv_ | oh and there is a way to associate the surface with the pixmap? I have been looking for that too, but didnt find anything that doesnt require some EXA specifics |
| 11:01 | jnettlet | sorry, delivery guy |
| 11:21 | jnettlet | and time to leave. dv_ I will catch up with you on this. I wonder if we should just use gco2D_ directly |
| 12:21 | jnettlet | dv_, I am getting the imx6 stuff rolled into a kernel so I can test better. I assume that is the graphics stack you are developing against. |
| 12:21 | dv_ | currently yes |
| 12:21 | dv_ | the linux-imx kernel |
| 12:21 | dv_ | I use OE and the meta-fsl-arm layer |
| 12:21 | dv_ | but ideally I would be able to use this GAL video sink for the cubox as well |
| 12:22 | jnettlet | correct. |
| 12:57 | jnettlet | must be quiet because everyone is out standing in line for their new iphone |
| 13:01 | dv_ | heh |
| 13:02 | _rmk_ | some of us are trying to put their network back together after sending a 51 message patch set to lots of recipients and totally killing their firewall |
| 13:03 | _rmk_ | it went so far that every single userspace process was waiting for the other processes to finish their IO, so the CPU was 100% idle and nothing in userspace could run |
| 13:03 | _rmk_ | way past the capabilities of the OOM killer to deal with |
| 13:04 | _rmk_ | the OOM killer wasn't even being triggered at that point |
| 13:06 | jnettlet | _rmk_, what mailer are you using? |
| 13:07 | jnettlet | postfix is usually quite well behaved in such instances. |
| 13:09 | _rmk_ | exim |
| 13:10 | _rmk_ | the problem is it sees lots of messages to the same host, and even if you ask it to deliver just one spool id, it goes "ooh look, I know all these other messages are for $host, I'll spawn a process to deliver them too irrespective of your resource control settings" |
| 13:10 | _rmk_ | which then causes the thing to spiral out of control |
| 13:10 | jnettlet | that seems like a problem |
| 13:11 | _rmk_ | I've taken to moving everything out of the queue, moving them back in and telling exim to deliver just that |
| 14:57 | jnettlet | wow 50 users. Look at this channel grow |
| 15:44 | Coolgeek | and 90% of them are idling.. |
| 15:44 | Coolgee | 15:44 * Coolgeek return to idle state |
| 15:54 | Marmott | 15:54 * Marmotte stays at idle state |
| 15:59 | dv_ | 90% of all inhabitants in any channel idle |
| 16:30 | _rmk_ | 98% of all statistics are a made up too. |
| 17:33 | setuid | I've got a weird issue with the cubox's default clocks |
| 17:34 | setuid | no matter what resolution or what monitor, if I'm connected via HDMI, the screen is about 1" too "big" all around all the edges |
| 17:34 | setuid | So any menus, icons, etc that are on the top/sides/corners, are off-screen |
| 17:34 | setuid | If I set my res to 1024x768, 1920x1080, anything at all, it's the same. |
| 17:35 | setuid | I'll get the standard black bars on the sides for 4:3 resolutions, but the mouse still goes "into the black" on those sides, disappears |
| 17:35 | setuid | Is there some way to fix this, or adjust it, so 1920x1080 pixels is really 1920x1080, and not 2000x1100 or whatever additional pixels it's adding? |
| 17:36 | cbxbiker61 | what does it say for resolution in /var/log/X*log |
| 17:37 | setuid | [ 473.988] (**) dovefb(0): Option "PreferredMode" "1024x768" |
| 17:37 | setuid | [ 473.990] (II) dovefb(0): 1024x768@60Hz |
| 17:37 | setuid | [ 473.994] (II) dovefb(0): Modeline "1024x768"x0.0 65.00 1024 1048 1184 1344 768 771 777 806 -hsync -vsync (48.4 kHz e) |
| 17:37 | setuid | and: |
| 17:37 | setuid | [ 474.632] (II) dovefb(0): MRVLCRTCResize: width 1024, height 768 display pitch 2048, screen width 1024, screen height 768, on scr pix: 0xb6f6b0c8, width 2048, height 2048, pitch 8192 |
| 17:37 | setuid | That's just when lightdm starts, I'm not even logging in at this point, just tryign to get the res right. If I log in, I can't log out, because the xfce4 menus are off-screen |
| 17:39 | cbxbiker61 | Kernel command line: console=ttyS0,115200n8 vmalloc=384M root=/dev/mmcblk0p2 ro video=dovefb:lcd0: |
| 17:39 | cbxbiker61 | 1920x1080-32@60-edid clcd.lcd0_enable=1 clcd.lcd1_enable=0 usb0Mode=host usb1Mode=host devtmpfs.mount=1 mtdpart |
| 17:39 | cbxbiker61 | s=spi0.0:512k(uboot)ro,128k(uboot_env) oprofile.timer=1 user_debug=0xffffffff profile=2 bootdelay=3 rootwait=3 |
| 17:39 | cbxbiker61 | that's how i have my kernel command line set |
| 17:40 | cbxbiker61 | in /var/log/X*log it says 1920x1080 as preferred resolution |
| 17:40 | setuid | I found that mkimage creates an image, but it doesn't actually do anything |
| 17:40 | cbxbiker61 | cat /proc/cmdline |
| 17:40 | setuid | Right, I changed preferred resolution, just to verify that this happens at every single resolution |
| 17:45 | setuid | Can you pastebot your boot.txt? |
| 17:45 | setuid | After you run mkimage, you can reboot, right? You don't need to reflash anything, is that correct? |
| 17:45 | setuid | I'm doing: |
| 17:45 | setuid | mkimage -A arm -O linux -T script -C none -n "uBoot commands" -d boot.txt boot.scr |
| 17:46 | cbxbiker61 | cat boot-ttyS0-console-part2.cmd |
| 17:46 | cbxbiker61 | echo ======== Setting bootargs ======== |
| 17:46 | cbxbiker61 | setenv bootargs 'console=ttyS0,115200n8 vmalloc=384M root=/dev/mmcblk0p2 ro video=dovefb:lcd0:1920x1080-32@60-edid clcd.lcd0_enable=1 clcd.lcd1_enable=0 usb0Mode=host usb1Mode=host devtmpfs.mount=1 mtdparts=spi0.0:512k(uboot)ro,128k(uboot_env) oprofile.timer=1 user_debug=0xffffffff profile=2 bootdelay=3 rootwait=3' |
| 17:46 | cbxbiker61 | echo ======== Loading kernel ======== |
| 17:46 | cbxbiker61 | ext2load mmc 0:1 0x00200000 /uImage |
| 17:46 | cbxbiker61 | echo ======== Booting kernel ======== |
| 17:46 | cbxbiker61 | bootm |
| 17:47 | cbxbiker61 | yeah, no need to do anything but turn the .cmd into .scr |
| 17:50 | setuid | Definitely fishy |
| 17:51 | setuid | It's almost like the config detects my monitor as being 1" or so larger around on all sides than it actually is, and paints the viewport that large |
| 17:51 | setuid | So everything on the perimeter is off-screen |
| 17:52 | setuid | I wish bootup would display something too, it just goes blank/black, until lightdm loads. Same on all monitors I've tried |
| 17:54 | setuid | Here's someone reporting the same problem: http://www.solid-run.com/phpbb/viewtopic.php?f=11&t=740&start=480 |
| 18:14 | setuid | Doesn't seem to like anything I've tried, from 30hz to 200hz refresh rate and clock lines |
| 19:28 | setuid | Looks like the dovefb driver is the problem |
| 19:35 | setuid | It's putting the viewport off-screen |
| 19:54 | setuid | xrandr --output lvds --set "scaling mode" Full |
| 19:54 | setuid | reports an error: "X Error of failed request: BadName (named color or font does not exist)" |
| 19:54 | setuid | I google'd it, no luck with any solutions |