Re: [MeeGo-dev] ARM 3D support was Re: [fedora-arm] ARM summit at Plumbers 2011
[ok i'm going to do another cross-post in a bit which will give some background and also perhaps some other topics for discussion, but i wanted to cover this first. apologies for people for whom this is just noise] On Tue, Aug 23, 2011 at 7:01 PM, omall...@msu.edu wrote: the xilinx zynq-7000 or similar (dual core Cortex A9 + FPGA). The idea is to have an OGP GPU in firmware in FPGA. In terms of the power budget, it seems to work relatively sanely considering what it is, and it is as ideal as it gets as far as openness and flexibility goes. I just thought it's worthy of a mention. It does seem outlandish, but it is kind of cool. Is it going to give enough 3d speed? The next gen tegra is supposed to have a 24 core GPU. if nvidia have a published announcement of their plans to release a fully free-software-compliant 3D driver to match the proprietary hardware, then that would be brilliant news [about their next gen GPU]. about the zynq idea: it actually doesn't matter if it's enough. the very fact that free software developers - and people who want to be free software developers - around the world could even _remotely_ consider buying one of these for an affordable price instead of $750 for the present OGP card means that more people can at least begin to try to address the unbelievably wide and very discouraging gap between us and proprietary 3D hardware. the NREs on producing a set of masks are _only_ $250,000 if you are a taiwanese company asking TSMC, but for everyone else they're at least $2 million. the development costs if you use off-the-shelf tools before you even _get_ to the point where you can ask a fab to produce those masks spiral out of control (Mentor Graphics charges something like $250,000 per month or maybe per week per user; NREs for peripheral hard macros can be $50k to $100k each etc. etc.), taking the total development costs in many cases to well above $USD 30 million. and that's excluding all that proprietary software which of course is utterly useless without the corresponding hardware but, because of USA Accountancy Rules, where IP can be added to the books to increase the value of a company, there's a strong financial disincentive to consider just givvin it aww away 4 fwee. and here we are with a CPU which could well be around the $25 - $30 mark in large enough volumes, presented with the possibility to say u all, you proprietary GPU companies and your greed, fear, patent warfare and lack of willingness to collaborate and cooperate. ok maybe not those exact words but you know what i mean :) l. ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] [Meego-handset] N900 and N900CE related bugs
Hi, We had nice conversation about this at IRC yesterday with Luis and Gary Birkett (lcuk) and I promised to send a short description via mailing list. The main problem is that CE and Vanilla aren't in sync and CE fixes doesn't work in Vanilla. This may lead to following: Bug reported with Vanilla image: - Might be ignored / marked as a duplicate for a bug existing in the CE. - If bug is fixed for CE, the bug is verified, but the fix is missing from Vanilla. Bug reported with CE image, reproduced with Vanilla: - Fixed and verified for the CE, Vanilla is ignored. So, we need to avoid these. But how? This might happen with other devices also, same hardware but different release, so let's try to find a good method to use not only with N900 but others to come also. One solution is to Clone the bug: - If reported for Vanilla and then reproduced with CE, the CE gets own clone bug and vice versa. - Fixing, releasing and verifying is done separately to both. And the bugs are still linked in a comment level, so nothing important isn't disappearing. One solution is to do as Luis proposed. - Problem: there isn't clear visibility in the bug if it's fixed for the image it has been reproduced later - Problem: if the bug is fixed for the image it's originally reported, but not to the other One solution is keep conversation ongoing in one bug and clone it IF needed - IF the bug is fixed with original image, then bug is cloned for the other image - If the bug is fixed for the image where it has been reproduced later, commenting that this is fixed and keep the bug open to show that originally reported bug isn't fixed/released - Problem: there isn't clear visibility in the bug if it's fixed for the image it has been reproduced later Best solution: - You name it. It must be one when all of us are happy (or at least somehow satisfied) : developers, testers, users, managers. I hope I could add everything needed to this bug. Please be active and tell what you think. Br, Iekku -Original Message- From: ext Luis Araujo [mailto:luis.ara...@collabora.co.uk] Sent: 18 August, 2011 03:55 To: Pylkka Iekku (EXT-Ixonos/Tampere) Cc: meego-dev@meego.com; meego-hand...@lists.meego.com Subject: Re: [Meego-handset] N900 and N900CE related bugs Hello Iekku, Let me summarise and see if I get this right: (*) Bugs reported for N900CE (or other derivatives) that are fixed but still reproduced in N900 Vanilla images: - Set status to RESOLVED/FIXED - Remove N900CE keyword - Add comment that it is verified for N900CE (It could be useful to add a comment stating that it is still reproduced in Vanilla image too) - Set status to VERIFIED only once the fix arrives to Vanilla image. The current procedures goes like that?, if I follow you right?, This sounds good for me. Now, my main concern and I also propose here a way to handle such a case is the following: (*) Bugs reported for N900 Vanilla images but the fix is _only_ available so far for N900CE or other derivatives: - Stay bug status as open (NEW, REOPENED...): This has some benefits in my opinion, for example, it avoids duplicating bugs, users testing in the Vanilla images will find this bug report and also add any comment if needed. - Once there is a fix for N900CE or other derivatives: Add a comment with the upstream merge or OBS submit request of such a fix. This way, Vanilla users finding this bug will find the fix is already available for one of the derivatives and they can just start using that instead if they want (hey ... project promotion through bug reporting :P) - Only set RESOLVED the bug once a specific decision or fix has been applied to this Vanilla image: a) Bug fixed: set RESOLVED/FIXED and VERIFIED later. b) Bug won't be fixed for N900 Vanilla image for X or Y reason (it is not always easy to know who takes this decision, Release Managers?, if RM are not sure, upstream developers could have a call here): the status is set to INVALID or WONTFIX, probably adding a comment stating the reasons. I see two main and important advantages of this approach: - Users of the image will still be able to find a bug report for the reproduced issue, hence avoiding duplicating bugs. - Users will be able to find where the fix is already available. This whole thing is probably a bit complex, like you said Iekku, but it'd be nice to make this clear so we can take full advantage of bug reporting for all these different image derivatives, we could come out with some guidelines not only for N900 platforms, but also any other ones. Hopefully this thread might help to clarify or set some of these guidelines :) , I would be glad to add this to the wiki if you think it is good enough. Please, comments, suggestions? Regards, - Luis On 08/17/2011 01:36 AM, ext-iekku.pyl...@nokia.com wrote: Hi, You have good point there. It has been agreed that bugs reproduced/reported only for N900CE can be verified after fix. If the bug is reproduced with
[MeeGo-dev] Using VaImagesink to display video in Overlay Plane in Meego
Hi All, I'm using vaimagesink to render the decoded video on the screen. Im trying to use VaImagesink to display the video in overlay plane. I enabled XVideo option in Xorg.conf. But im not able to test whether the video plays in overlay plane. Can someone help me with the steps to verify whether the video plays in overlay plane. Regards, Kirrthana ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] OBS oddities
Hi, I have a spec file that I am trying to upload to the OBS server. Actually, I have previously uploaded it from my Linux box. The spec file was processed, however, I had failed to add in some BuildRequires. When I add in those requires and upload from a windows box the spec file isn't working - getting the following error: error: Macro %with_module_engine_software_x11 has empty body error: Macro %with_lib_ecore_fb has empty body error: line 24: Unknown tag: 1 After some troubleshooting - it seems that I get these errors from editing the files with Wordpad on windows. I've come to this conclusion by taking a *working* spec file opening/saving via wordpad and placing it back, only to get the afore mentioned error. Does anyone know how to work around this? I am stuck on the Windows box most of the day, so it would be nice to do some work on things from it... Nasa ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] OBS oddities
2011/8/24 Nasa nas...@comcast.net: Hi, I have a spec file that I am trying to upload to the OBS server. Actually, I have previously uploaded it from my Linux box. The spec file was processed, however, I had failed to add in some BuildRequires. When I add in those requires and upload from a windows box the spec file isn't working - getting the following error: error: Macro %with_module_engine_software_x11 has empty body error: Macro %with_lib_ecore_fb has empty body error: line 24: Unknown tag: 1 After some troubleshooting - it seems that I get these errors from editing the files with Wordpad on windows. I've come to this conclusion by taking a *working* spec file opening/saving via wordpad and placing it back, only to get the afore mentioned error. Does anyone know how to work around this? I am stuck on the Windows box most of the day, so it would be nice to do some work on things from it... Get an editor that can work with UNIX style line endings, i,e, LF, not CRLF llike Windows has it. Notepad++ or something maybe. BR Carsten Munk Nasa ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] [fedora-arm] ARM summit at Plumbers 2011
On Tue, Aug 09, 2011 at 07:15:34PM +0100, Steve McIntyre wrote: Hi folks, Following on from the founding of the cross-distro ARM mailing list, I'd like to propose an ARM summit at this year's Linux Plumbers conference [1]. I'm hoping for a slot on Thursday evening, but this remains to be confirmed at this point. We had some lively discussion about the state of ARM Linux distros at the Linaro Connect [2] event in Cambridge last week. It rapidly became clear that some of the topics we discussed deserve a wider audience, so we're suggesting a meetup at Plumbers for that bigger discussion. ok. allow me to give some perspective and background as to why i believe that a bigger discussion is important, and to whom that discussion is important. a few years ago i read what seems like a silly book, called The Strategy-Focussed Organisation. sounds trite, but i was advised to read it when i proposed some ideas and was confronted with the very valid question why should i [a lowly developer] _care_ about this 'strategy' that you are proposing? (fortunately the person who asked the question was the same one who advised me to read this silly book). it's a tough one, isn't it? why should any of us - as free software developers - _care_ about the state of ARM Linux? you're getting on with the truly crucial task of managing the distro that you're committed to. it's a focussed job: it's a vital role, and you should not let anyone tell you otherwise. yet... and this is the bit that this silly book explained: it's just as important to know where *your* role fits in with what else is going on. linaro, for example, as you no doubt well know, is tasked (by its subscribers who pay $1m / year) with sorting out vital underlying infrastructure that ties what *you* are doing in with the subscriber's ARM CPUs. you're doing the user-facing stuff; they're doing the CPU-facing stuff. that's *their* strategic role: in concrete terms it means sorting out gcc with ARM optimisations, and it means seeking out and/or increasing the number of areas of shared and refactored code across as many places as possible, in order to reduce the software development effort required of their subscribers. linux kernel. device tree. LSB. (and, it has to be said, _if_ the stupid, stupid 3D GPU companies got with the picture, linaro could well take gallium3d for example under its wing, too). so the key question is: if linaro is taking care of this aspect, because that's linaro's role, then why _should_ any distro maintainer care? yes they should be aware of what's happening, but there's no real incentive to get pro-actively involved, is there? all that's required is passive acceptance of the work filtering down from linaro... and this perhaps explains the lack of response to the proposed meetup, steve. [the other reason is that yes, although _discussion_ can take place about 3D GPUs, we as free software developers feel powerless to act in the face of so much money. despite the fact (which personally makes me extremely angry) that without our overall contribution these companies simply would not have a gnu/linux distro or a linux kernel on which to make that money]. so, the important question to ask, then, is what *is* good motivation to take action? if, indeed, any action need be taken at all, which is a perfectly reasonable conclusion to reach. not that i personally agree with that, but i can live with it :) and, to answer that question, i feel it's important to take into account some context and background. many of these things you will already be aware of, but let me put them all together, here. take a deep breath... * with the rise of android, Matt Codon shows us an empirical glimpse into the blatant state of GPL violations by OEMs taking place on the Linux Kernel and more: http://www.codon.org.uk/~mjg59/android_tablets/ * many android vendors have lost the right to use linux kernel source code. this article is the most insightful and non-aggrandising i've yet found into the GPL violations situation and its consequences: http://fosspatents.blogspot.com/2011/08/most-android-vendors-lost-their-linux.html * Our Linus declared in april that he was getting fed up with the state of the ARM Linux Kernel. my take on this is that there is an overwhelming amount of selfishness creeping into the Linux Kernel development. Our Linus has also recently stated that his passion is actually low-level device driver development. http://thread.gmane.org/gmane.linux.kernel/1114495/focus=112007 * Russell King, the ARM maintainer, has completely lost all motivation to work on the task of merging ARM Linux patches. with the amount of selfishness that has been going on for so many years, i am surprised he's tolerated it this long. http://article.gmane.org/gmane.linux.kernel/1121096 * I've seen proposed solutions and many many descriptions of the problems caused by the rise of ARM Linux, but none of them look at this from an overview
Re: [MeeGo-dev] OBS oddities
- Original Message - 2011/8/24 Nasa nas...@comcast.net: Hi, I have a spec file that I am trying to upload to the OBS server. Actually, I have previously uploaded it from my Linux box. The spec file was processed, however, I had failed to add in some BuildRequires. When I add in those requires and upload from a windows box the spec file isn't working - getting the following error: error: Macro %with_module_engine_software_x11 has empty body error: Macro %with_lib_ecore_fb has empty body error: line 24: Unknown tag: 1 After some troubleshooting - it seems that I get these errors from editing the files with Wordpad on windows. I've come to this conclusion by taking a *working* spec file opening/saving via wordpad and placing it back, only to get the afore mentioned error. Does anyone know how to work around this? I am stuck on the Windows box most of the day, so it would be nice to do some work on things from it... Get an editor that can work with UNIX style line endings, i,e, LF, not CRLF llike Windows has it. Notepad++ or something maybe. Thanks for the suggestion... Which I would love to do, but I don't have control over these machines... Guess I should wait till I get home. Nasa BR Carsten Munk Nasa ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] OBS oddities
If you can't install editors then the OBS gui allows editing of files. Nasa wrote: - Original Message - 2011/8/24 Nasa nas...@comcast.net: Hi, I have a spec file that I am trying to upload to the OBS server. Actually, I have previously uploaded it from my Linux box. The spec file was processed, however, I had failed to add in some BuildRequires. When I add in those requires and upload from a windows box the spec file isn't working - getting the following error: error: Macro %with_module_engine_software_x11 has empty body error: Macro %with_lib_ecore_fb has empty body error: line 24: Unknown tag: 1 After some troubleshooting - it seems that I get these errors from editing the files with Wordpad on windows. I've come to this conclusion by taking a *working* spec file opening/saving via wordpad and placing it back, only to get the afore mentioned error. Does anyone know how to work around this? I am stuck on the Windows box most of the day, so it would be nice to do some work on things from it... Get an editor that can work with UNIX style line endings, i,e, LF, not CRLF llike Windows has it. Notepad++ or something maybe. Thanks for the suggestion... Which I would love to do, but I don't have control over these machines... Guess I should wait till I get home. Nasa BR Carsten Munk Nasa ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] OBS oddities
Which I would love to do, but I don't have control over these machines... Guess I should wait till I get home. Notepad++ can be run without installation, just extract the zip. To change the CR/LF use the menu Edit / EOL Conversion. - Fernando ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
Re: [MeeGo-dev] OBS oddities
Fernando, Thanks a lot! Good things to know, Nasa - Original Message - Which I would love to do, but I don't have control over these machines... Guess I should wait till I get home. Notepad++ can be run without installation, just extract the zip. To change the CR/LF use the menu Edit / EOL Conversion. - Fernando ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
[MeeGo-dev] Building RPMs on OBS
Hi again, as I work my way through this, I keep coming up with things I just don't understand... The question for now, is about spec files. I am repackaging some libraries that have spec.in files which get turned into .spec files from autogen.sh. I have a spec file that is outside the tar.gz that contains the source code. Does the outside spec file need to match the inside spec file? I ask because I am getting rpmlint errors that don't make sense for the spec file that is outside the tar.gz. Thanks for your understanding :} Nasa ___ MeeGo-dev mailing list MeeGo-dev@meego.com http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
