Re: vMeta GStreamer 1.0 plugins
On Thu, Aug 22, 2013 at 6:48 AM, Carlos Rafael Giani d...@pseudoterminal.org wrote: First, I will paste from a chat I had in IRC with an X and Wayland developer: dv_ are you familiar with xvideo together with xshm? dv_ if not, who could know about internals? daniels hi, sure daniels what about it? dv_ the problem is that there seems to be no guarantee that xvshmputimage actually finished drawing the frame internally when it returns dv_ causing this bug: http://dev.laptop.org/ticket/12644#comment:7 dv_ I have experienced a related problem. my decoder sends the frame to xv, where it is drawn, and xvshmputimage apparently returns too soon. so, frame buffers that havent been fully read yet by the driver are filled with new data daniels yeah, there's a 'completion' event for that, analogous to wl_buffer::release dv_ I tried that one, didnt help dv_ is there a known issue with this? daniels oh daniels no, your driver's buggy then, if it sends a completion before it's finished using the frame dv_ okay daniels tbf, the server does always send a shm completion event _immediately_ after XvdiPutImage returns, and there's no facility for doing otherwise daniels so if your driver does anything other than copy the data out immediately (e.g. schedules a draw using that area), then it's going to be buggy dv_ this could very well be dv_ because the hack that was added to it uses (actually abuses) the shm buffers as carriers for physical addresses dv_ that is, instead of copying pixel data, it writes a 32bit-address into it, plus a magic number dv_ the driver sees that magic number, knows that the next 4 bytes arent pixels but a physical address, and draws the pixels from that address daniels hah, right daniels yeah, you'd need to add new server - driver api for delayed completions dv_ so I guess either I have to block XvdiPutImage until the hardware has drawn it fully, dv_ or add something extra, yes dv_ to add credence to that theory, I put an usleep call right after xvshmputimage(). 10ms. the flickering disappeared. daniels haw daniels oh yeah, and with the second-last para, what you'll be seeing there is the ReputImage hook, i suspect daniels if the window isn't yet visible, it'll just bin all the drawing requests daniels but when it comes with a non-zero clip, suddenly it'll just fire requests at the driver's ReputImage hook That is interesting, nice to have some expert input backing up my findings on #12644. So I looked into the dove driver in the kernel, and I see nothing to cause the driver to wait for the hardware to finish the drawing. I tried adding a vsync wait, but that did not help. (Or perhaps I put it in the wrong place?) Maybe you have overtaken me in your understanding here, but from the above conversation, I can't see how this is related to the kernel driver. Instead we face these problems: 1. The X client cannot assume that the image has been drawn by the X driver after XvShmPutImage(). It might be drawn some time later. 2. The X client cannot assume that the image has been drawn by the X driver after XvShmPutImage(). It might never be drawn at all. 3. There is no alternative way of communicating that required information from the X driver to the X client (unless we implement something). So as far as I understand, this communication problem sits between the X client and DDX, not related to the kernel, and there is nothing that the DDX can immediately do about it (tbf, the server does always send a shm completion event _immediately_ after XvdiPutImage returns, and there's no facility for doing otherwise) John Nettleton then told me they don't have this issue because the OLPCs use the GPU for drawing, so the driver will use the texturedoverlay path. I cannot use the GPU mode, since then, symbols are missing (gcoHAL_QuerySeparated3D2D). We definitely do have the issue described at #12644 and clarified by daniels. I did work around it in a way that will result in occasional bad frames being drawn (flickering?) but we have not seen that so far with gstreamer-0.10. If that problem is avoided due to using textured overlays, I am not sure why, but it may be so. I will try to run your code in the next few days and see if we do see the flicker issue. Note that we work with two versions of libgalcore, one for each version of our hardware. The XO-1.75 version that runs against an older version of libgalcore does not use that symbol. You can find it in the xo-1.75 branch of http://dev.laptop.org/git/projects/xf86-video-dove/ Daniel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Boot os 13.2.0 from SD card (XO-1, XO-1.5)
Hi- I'm trying to make an OS install SD card for 13.2.0 for an XO-1.5 and XO-1 in order to speed things up and to allow more memory for yum installs. Unfortunately, things seem to have changed a lot since the last time I went through this process circa the os 8.2 release. I've been trying to follow the directions from the OLPC Wiki on the following pages: http://wiki.laptop.org/go/OS_images_for_USB_disks http://wiki.laptop.org/go/Custom_bootloader but they are mostly out of date enough so that I can't connect the dots to get a working version by myself. In fact, if I have an ext2/ext3/ext4 file system on the SD card, the OFW doesn't even see the card (it does if the fs is FAT32). Are there any updated/consolidated instructions for an SD card boot creation (as used to be available in the standard OS builds)? Thanks in advance, Chris ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Boot os 13.2.0 from SD card (XO-1, XO-1.5)
On Thu, 2013-08-22 at 19:52 +, Chris Marshall wrote: Hi- Hi Chris, I'm trying to make an OS install SD card for 13.2.0 for an XO-1.5 and XO-1 in order to speed things up and to allow more memory for yum installs. Just to be clear here, you what to run the os from the external SDcard slot? or install from the SDcard slot to the internal storage? Have you looked at olpc-os-builder to create an image with your rpms pre-installed? Unfortunately, things seem to have changed a lot since the last time I went through this process circa the os 8.2 release. I've been trying to follow the directions from the OLPC Wiki on the following pages: http://wiki.laptop.org/go/OS_images_for_USB_disks http://wiki.laptop.org/go/Custom_bootloader but they are mostly out of date enough so that I can't connect the dots to get a working version by myself. In fact, if I have an ext2/ext3/ext4 file system on the SD card, the OFW doesn't even see the card (it does if the fs is FAT32). Are there any updated/consolidated instructions for an SD card boot creation (as used to be available in the standard OS builds)? To install to an external SDcard for 1.5, 1.75, 4's you would need to have your *.zd file on a usb flashdrive inserted into the XO, access OFW's OK prompt then type: devalias fsdisk ext:0 enter fs-update u:\image.zd enter enter is the enter key replace image with the name of the image you want to install. Please remember that *1.zd is for XO-1.5's, *2.zd is for XO-1.75's, *4.zd is for XO-4's. Jerry Thanks in advance, Chris ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Boot os 13.2.0 from SD card (XO-1, XO-1.5)
On Thu, Aug 22, 2013 at 8:54 PM, Jerry Vonau jvo...@shaw.ca wrote: On Thu, 2013-08-22 at 19:52 +, Chris Marshall wrote: Hi- Hi Chris, I'm trying to make an OS install SD card for 13.2.0 for an XO-1.5 and XO-1 in order to speed things up and to allow more memory for yum installs. Just to be clear here, you what to run the os from the external SDcard slot? This one. or install from the SDcard slot to the internal storage? Have you looked at olpc-os-builder to create an image with your rpms pre-installed? Not yet, still on the early learning curve. Unfortunately, things seem to have changed a lot since the last time I went through this process circa the os 8.2 release. I've been trying to follow the directions from the OLPC Wiki on the following pages: http://wiki.laptop.org/go/OS_images_for_USB_disks http://wiki.laptop.org/go/Custom_bootloader but they are mostly out of date enough so that I can't connect the dots to get a working version by myself. In fact, if I have an ext2/ext3/ext4 file system on the SD card, the OFW doesn't even see the card (it does if the fs is FAT32). Are there any updated/consolidated instructions for an SD card boot creation (as used to be available in the standard OS builds)? To install to an external SDcard for 1.5, 1.75, 4's you would need to have your *.zd file on a usb flashdrive inserted into the XO, access OFW's OK prompt then type: devalias fsdisk ext:0 enter fs-update u:\image.zd enter enter is the enter key replace image with the name of the image you want to install. Please remember that *1.zd is for XO-1.5's, *2.zd is for XO-1.75's, *4.zd is for XO-4's. This worked perfectly. Is there something comparable for a G1G1 XO-1? --Chris Jerry Thanks in advance, Chris ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: Boot os 13.2.0 from SD card (XO-1, XO-1.5)
On Thu, Aug 22, 2013 at 07:52:44PM +, Chris Marshall wrote: In fact, if I have an ext2/ext3/ext4 file system on the SD card, the OFW doesn't even see the card (it does if the fs is FAT32). Which version of Open Firmware? I did a lot of work to fix this. Consider upgrading to the latest. [1] It works for me. Perhaps you have an unusual partition table or filesystem features enabled? Happy to diagnose further; to test it, get to the Ok prompt [2] and type: dir ext:\boot\olpc.fth and show me what happens. You might use a serial console [3] or telnet [4] to capture the result. 1. http://wiki.laptop.org/go/Upgrading_firmware 2. http://wiki.laptop.org/go/Ok 3. http://wiki.laptop.org/go/Serial_adapters 4. http://wiki.laptop.org/go/Firmware/Remote#Using_telnetd Most likely cause is old firmware, or not setting bootable flags on partitions. Are there any updated/consolidated instructions for an SD card boot creation (as used to be available in the standard OS builds)? No, the instructions for the current 13.2.0 release on XO-1.5, XO-1.75, and XO-4 require combining content from two pages: http://wiki.laptop.org/go/Firmware/Storage#How_to_install_to_SD_card http://wiki.laptop.org/go/Release_notes/13.2.0#Installation I'd rather not have the release notes explain the option of SD card install, because it is rare and would complicate the installation instructions for the majority of users who are installing to internal storage. Feel free to wipe out those old instructions once you have it figured out for 13.2.0. To install to an external SDcard for 1.5, 1.75, 4's you would need to have your *.zd file on a usb flashdrive inserted into the XO, access OFW's OK prompt then type: devalias fsdisk ext:0 enter fs-update u:\image.zd enter enter is the enter key replace image with the name of the image you want to install. Please remember that *1.zd is for XO-1.5's, *2.zd is for XO-1.75's, *4.zd is for XO-4's. This worked perfectly. Is there something comparable for a G1G1 XO-1? No. The missing components would need to be inserted into the dracut scripts, to locate the root filesystem. Then regenerate the initramfs. We had discussion on this recently on server-devel@ or devel@. -- James Cameron http://quozl.linux.org.au/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
