Open tomas opened 6 years ago
No, currently there are no plans. Sadly something changed to Debians and therefore Ubuntu packaging system, so the dependencies of EMGD need some updates. Currently I don't have the time to fix the issues around these packages :disappointed:
Bummer... :(
I might have some time myself (eventually) though. Would you point me in the right direction in order to get the packages built?
Are you really interested to work on this? Actually, I was about to close this EMGD project just because people are asking about progress, but they are not willing to help out or continue this work. If you like we can begin with the essentials to get OpenGL working: Mesa and Xorg For the kernel driver, we can always use an older kernel I guess.
If you are interested I can re-upload the mesa sources again. The issue with it seems to be packaging related - that means: You will need to fix a Makefile to the latest standards set by Debian. If I recall correctly there was an issue with a debhelper command, which was complaining, that a directory was passed as an argument. This happens because a regular expression is including a subdirectory.
So, if you are interested I can re-upload it for you and you can try to fix it. Whenever possible, I will help, but don't expect a big interest from my side, because my netbook's battery is completely dead. The only reason I'm keeping it, is, that I would like to use it within a build system. But that is another story.
Yes, please do!
As I said I'm not sure when I'll be able to put time into this, but I also own a few netbooks and would love to keep them up do date.
I'm uploading the sources at the moment.
Please focus on the master
branch, which contains mesa 7.9. As far as I remember, the binary blobs by Intel were most stable with it.
Here is the last build log:
https://launchpadlibrarian.net/348769185/buildlog_ubuntu-bionic-i386.mesa-7.9_1%3A7.9-201712102304~rev46~ubuntu18.04.1_BUILDING.txt.gz
And the troubling line at the end of the build log.
dpkg-gensymbols: error: cannot read debian/libegl1-mesa-7.9/usr/lib/i386-linux-gnu/mesa-7.9-egl/egl: Is a directory
Good luck! :+1:
Hint: Download the latest mesa source package from Ubuntu and look how they updated this section. This might save time :)
Great, thanks. Do you have the build script you used for building the packages? Now that would save me a lot of time. :)
Go into the source directory and execute dpkg-buildpackage
.
Were you able to upload the mesa source code? I just cloned the repo for a first attempt, but I can't find any traces of it anywhere (they should be inside debian/libegl1-mesa-7.9
, right?).
Thanks again
Nope, the packaging files (./debian/) are inside the source directory (./). When the binaries are built the files are placed into directories, eg. debian/libegl1-mesa-7.9, which at the end get archived into single files. Eg. libegl1-mesa-7.9.deb.
Quick question: am I supposed to build the packages inside a chroot? I'm having trouble setting everything up (i.e. I'm running a x64 machine but dpkg-buildpackage complains about the linux-headers-686 package not being present).
Is there something else I'm supposed to do? The output I get from dpkg-buildpackage
doesn't even look close to the build log you pointed earlier, haha. :)
Yes, using a chroot is fine. Also using a VM would work, but is not as lightweight as a chroot. Take a look at "schroot". It allows to use chroots pretty easy even without gaining root rights!
The log I posted before is the one from launchpad.net's builder. They use a bare minimal chroot and then reinstall all packages as needed for the package to be built. To reproduce the build process from launchpad.net I recommend to take a look at "pbuilder".
Happy easter!
I'm getting the same error. and as you mention cause of debhelper.
dh_makeshlibs will run dpkg-gensymbols on all shared libraries that it generates shlibs files for. So -X can be used to exclude libraries. Also, libraries in unusual locations that dpkg-gensymbols would not have processed before will be passed to it, a behavior change that can cause some packages to fail to build.
I could install xorg and mesa from xenial didn't have time to make all tests but it should work...
I'd be willing to help keep this alive too. Lord knows i have the time. I might need some pointers sometimes though if you are willing thopiekar. I waited 7 years to get my hands on a umid mbook just to stumble on this poulsbo mess intel created. I've got a sagem spiga too (umid mbook m1 clone) I'd really like to keep my quite rare machines going as long as i can. Owners of the Onkyo bx407a4 would benefit too. You still around tomas? Perhaps we could work together. I've been meaning to package all this for the Arch User Repository for about 2 years but never got round to it. If anyone needs bare metal i can leave an ssh server running on one of these netbooks and fill a 64gb pendrive full of different distro chroot's.
P.s. I've definitely benefitted from your work thopiekar and i greatly appreciate what you've done to keep this chipset alive for so long. I've just never really known how i could contribute.
Yes, still around @deagon88.
I haven't made any further attempts, but maybe in the next weeks I'll put some time into this.
Cool, np mate. I've just had a stab at getting this running on LMDE and ran into a bunch of problems. I'll just keep figuring out what it takes to get it running on this distro for now and writing down what i did. I still have a text file full of steps i took to get this working on ubuntu 16.04. I'll give ubuntu 18.04 a bash after i'm done with lmde.
Luckily linux 4.4 has a projected EoL in Feb 2022. No idea what we can do then if we still can't get this intel driver to build and work on newer kernels. That's a bit out of my depth frankly, a bit of packaging i can manage though. I'll need to get dug into the debian packaging manpages first, I haven't done any debian packaging since debian lenny.
I think best way to make it working would be to compile from sources... The error is not critical script needs to be ajusted... But I'm not a scripting guy ...
I created a pull request at https://github.com/EMGD-Community/mesa/pull/1 that appears to fix the issue. The wildcard * was picking up the egl directory, so I just changed it to only pickup .so files instead and the packages built successfully . I'm guessing in older versions of Ubuntu the wildcard didn't pick up the egl directory.
Is there any real interest in getting a running PPA again? I archived all repositories I had here before here on Github on a private GitLab server. Also, I haven't had the impression that someone wants to continue on this. Can reupload all repositories (libva, Xorg, etc.) again if you like! ๐
@thopiekar YES! Getting the PPA up to date would be great. There's at least four of us who are interested in using updated EMGD drivers, and I suspect the number will increase over time (considering these laptops are becoming collectibles).
@thopiekar: Yes please, that would be great! I'm wanting to use EMGD on a OpenFrame 2 device.
I think I know why xserver-1.9 isn't building on Ubuntu Bionic. It's looking for xfont.pc, but libxfont-dev on Bionic contains xfont2.pc
@thopiekar Yes please. I'd like to keep my netbooks running. I've no time right at this moment, I'm hurridly finishing off other stuff i've been working on first before picking this up.
@thopiekar: I was looking into why xorg-server wasn't building, and it's due to configure failing to detect xfont. This used to be provided by the libxfont-dev package, but in Bionic that package contains xfont2 not xfont.
I did find a libxfont1-dev package at https://launchpad.net/ubuntu/bionic/amd64/libxfont1-dev/ but it's not in the main repository anymore (status shows as "deleted"). When I downloaded the .deb file (along with libxfont1) and manually installed them using dpkg -i, the xorg-server packages built correctly.
I'm not sure how to reference those packages as part of building xorg-server other than manually installing them.
Alright! I'm going to push the sources back to GitHub ๐
You can also work on my GitLab which is running on my NAS, but I guess it makes more sense to use GitHub first. If someone wants to play with custom CI solutions, we can talk about using my infrastructure again ๐
@trs79 I have copies of all software which was needed in the past to build Mesa, Xorg and libva. Something I noticed is that some dependencies led to errors because they were too recent. Therefore I created new *-dev packages, eg. mypackage-{version}-dev, which conflicted against mypackage-dev. This way I was doing a downgrade, which ensured that both -dev packages are not installed at once. But yeah, you will see! Hope that everything you need will be there. ๐
@trs79 You are right. libxfont is a new one that is too new. Ubuntu provides libxfont >2.0, but we need something around 1.x.x, because there seem to be API changes.
Found the last 1.x release in https://salsa.debian.org/xorg-team/lib/libxfont/tags with packaging and dropped it into https://github.com/EMGD-Community/libXfont/tree/salsa.debian-libxfont1-1_1.5.2-4 So what needs to be done is:
As soon as this is done and we got a working Xserver, then I'll continue uploading the other sources.
Good luck! :wink: :+1:
I cheched build of xorg-server-1.9 now the problem is only cause "No package 'xfont' found" ?
@thopiekar: Thanks for uploading the sources and the help. I followed your instructions and created a pull request for libxfont and xorg-server. The new libxfont packages are libxfont-1.5.2 and libxfont-1.5.2-dev. Please let me know if you need any changes.
Good news. Thanks to @trs79 and some little adjustments I made, we are going to receive Xserver 1.9 soon: https://code.launchpad.net/~thopiekar/+recipe/xserver-xorg-emgd
(At least the build for Ubuntu Xenial was working so far, but think the others will work, too.)
@thopiekar: I also think we will need to add gstreamer0.10 and gstreamer-plugins-base0.10 to the list of packages no longer in Ubuntu Bionic but still needed by EMGD, at least for libva support
Well, at this point I think it doesn't make much sense anymore. Seriously.. Downgrading gstreamer would mean that you also need to downgrade all the other applications which depend on it. This to summarize you will need to downgrade nearly the whole desktop environment. Don't know how much sense it makes.. What do you think?
hmm, good point. Without downgrading gstreamer is there any way to keep libva support in EMGD?
Yes, the gstreamer plugins which are provided by Intel for EMGD access the video accelerator directly. The libVA driver kind of does the same, if I'm not wrong. But we have nearly the same problem with libVA, too. libVA was in these days in an early stage. Intel (maintainer of libVA) changed the API several times and the documentation was not great. As a consequence players, like VLC, mpv or MPlayer, never had good support for libVA and today newer versions of these players don't support older libVA anymore. So you'll need to take an older version and cross fingers. The only player, which had support for both in the past was XBMC, but don't know whether it is the same today with KODI. Could be that the KODI team dropped support for older libVA versions.
Hi, For me KODI 17 on Ubuntu 14 is using VAAPI...
@thopiekar: Thanks for the information on libVA, that is very helpful.
I have been able to get the gstreamer0.10 and gstreamer0.10-plugins-base packages to build in Bionic (copied from Debian Jessie, with some patches I created). Would you be opposed to adding those packages to Launchpad, just so EMGD will build? For those who don't want to downgrade their desktops, they can still use the other EMGD packages without gstreamer. For those who don't use a desktop (like in my case) gstreamer would be available.
Does libVA compiles?
Yes, libva compiles with gstreamer0.10
It would be interesting to try if new KODI works with it, will wait till thopiekar updates Launchpad, I couldn't compile on my pc.
Hi,
Yes, libva compiles with gstreamer0.10
Can you please provide the code I would like to try it... Thanks.
I will try to grab the libva .so file and post it here
you have it precompiled ? For what Kernel ?
Not directly relevant, but now that you have an accelerated X server (awesome BTW) then it enables use of a broadcom crystal HD video decoder, which to some extent solves the video decoding issues. With the open source modesetting driver there is no acceleration at all (not even XVideo for scaling) and no vsync support, so you can't actually paint the screen fast enough even with a separate decoder card.
I will try to grab the libva .so file and post it here
Any success ?
I apologize for the delay in response, it's been hard to find time. I'm attaching a zip file with all the .deb files I created. They are for i386 because the device I'm using only has a 32 bit cpu. I hope that is helpful, you should be able to install them with dpkg in Ubuntu Bionic 18.04. If there are any more needed .debs, please let me know.
libva-i386-debs.zip gstreamer-i386-debs.zip xserver-i386-debs.zip emgd-i386-debs.zip
Thanks, will try them tomorrow, where you able to compile EMGD driver ?
I updated my prior post to add the xorg and emgd debs
Tomorrow will try on Joggler and see if xbmc will work corectly with it, thanks...
I hope it works well for you. I actually am using emgd on a Joggler also, although I havent tried xbmc
tried on 5.2 kernel didn't work only xorg worked fine will try now on 4.2, what kernel are you using ?
Hi and congrats for your work!
I noticed that the packages on the PPA don't include anything after Ubuntu 16.04. Is there anything in particular that's preventing the drivers from working or being built on newer Ubuntu versions (16.10, 17.04, 17.10)? I'd love to try and build the drivers myself but couldn't find any info in the readme.
Thanks again