search

EMGD-Community / intel-binaries-linux

Binaries and source code published by Intel®
https://thopiekar.eu:5443/EMGD
Other
37 stars 11 forks source link

Installing EMGD on Debian? #45

Open James-E-A opened 6 years ago

James-E-A commented 6 years ago

With issue #33 being mistakenly asked and then closed (the issue being "resolved" by the user realizing the psb_gfx driver served his needs), I was wondering myself whether it's possible to use EMGD on Debian.

I see that there's a folder ./debian, which seems to contain files like control and rules which are known for being used for compilation of Debian packages, but are there any usage instructions, precompiled packages, or has anyone even used them?

I'd be interested in testing this out, see if I can't revitalize this AO751h netbook with a fresh Stretch desktop installation..

James-E-A commented 6 years ago

Preliminary testing with a small fixup (JamesTheAwesomeDude/intel-binaries-linux@3a2c57abef59c8c6c1b80a9d45197200b6e22eb1) yields this error:

make[1]: Entering directory '/root/intel-binaries-linux'
set -e ; for DISTRIBUTION in \
    fedora14 meego1.2 meego-wayland tizen1.0 ; do \
        dh_makeshlibs -pxserver-xorg-1.9-video-emgd-$DISTRIBUTION -- -c4 \
        -edebian/xserver-xorg-1.9-video-emgd-$DISTRIBUTION/usr/lib/i386-linux-gnu/emgd-$DISTRIBUTION/\* \
                        -edebian/xserver-xorg-1.9-video-emgd-$DISTRIBUTION/usr/lib/i386-linux-gnu/emgd-$DISTRIBUTION/dri/\* \
                        -edebian/xserver-xorg-1.9-video-emgd-$DISTRIBUTION/usr/lib/i386-linux-gnu/emgd-$DISTRIBUTION/xorg/\* \
    ; done
objdump: debian/xserver-xorg-1.9-video-emgd-fedora14/usr/lib/i386-linux-gnu/emgd-fedora14/ld.so.conf: File format not recognized
dh_makeshlibs: Compatibility levels before 9 are deprecated (level 7 in use)
dpkg-gensymbols: error: cannot read debian/xserver-xorg-1.9-video-emgd-fedora14/usr/lib/i386-linux-gnu/emgd-fedora14/dri: Is a directory
dh_makeshlibs: failing due to earlier errors
debian/rules:54: recipe for target 'override_dh_makeshlibs' failed
make[1]: *** [override_dh_makeshlibs] Error 255
make[1]: Leaving directory '/root/intel-binaries-linux'
debian/rules:10: recipe for target 'binary' failed
James-E-A commented 6 years ago

Stealing Jessie's packages for libgstreamer-plugins-base0.10-dev libgstreamer0.10-dev libgstreamer0.10-0 libgstreamer-plugins-base0.10-0 gir1.2-gst-plugins-base-0.10 gir1.2-gstreamer-0.10 has gone seemingly without consequences, and removed the necessity for --no-check-builddeps, but it also doesn't fix the error.

JacekJagosz commented 6 years ago

Please, if you manage to get it working, could you make a short tutorial or just list what you did to help the others? I've tried to install it already on a few different distros and failed every time.

James-E-A commented 6 years ago

@Jacek13 This is a bit OT, technically, I suppose, but the only distro I've actually managed to get this driver working on is Fedora 14. (And not via this repo or Intel's download.)

I was sadly unable to get @thopiekar's PPA working even on just a baseline Xenial Minimal Netinstall with Fluxbox. I see that the packages are still technically being compiled..for even as recent as Artsy...but is it maintained in a real capacity? I would love to hear anything from the developers about what the status of this is.

Re:F14, what I did was add the following to /etc/yum.repos.d/timesys-f14.repo and then install intel-emgd-{driver-extras,kmod} xorg-x11-drv-{evdev,synaptics} (be sure to uninstall the kernel that comes bundled with it)

[timesys]
name=Timesys - Fedora $releasever - $basearch
failovermethod=priority
baseurl=http://repository.timesys.com/buildsources/fedora/$releasever/$basearch/os/
#http://some.mirror/timesys-fedora/$releasever/$basearch/os/
enabled=1
metadata_expire=7d
gpgcheck=0

[timesys-source]
name=Timesys - Fedora $releasever - $basearch - Source
failovermethod=priority
baseurl=http://repository.timesys.com/buildsources/fedora/$releasever/source/
#http://some.mirror/timesys-fedora/$releasever/source/
enabled=1
metadata_expire=7d
gpgcheck=0

(When installing F14, you'll need to sed -i s/https/http/ all the repos you use since its SSL library is too old)

The thing is, though, F14 seems to interact violently with Bedrock Linux, and the Timesys EMGD kernel is too old to compile (and presumably? run, but I didn't bother trying to switch kernel, compile, switch kernel, run) a decent web browser..so it doesn't seem like it'll be a viable solution.

(Their repo for F18, baseurl=http://repository.timesys.com/buildsources/fedora/$releasever/$basearch/{release,updates,source}/ did not seem to work for EMGD, though)

James-E-A commented 6 years ago

Although, @Jacek13 if you want to get started on this, all you have to do to mimic my progress is (IIRC)

thopiekar commented 6 years ago

Interesting that the EMGD driver is still needed like that, even that I stopped maintaining it for years. All needed dependencies you need are in the community page here. To make the driver working you need the following:

For video acceleration you need:

The reason I still use Ubuntu until today is launchpad.net, where I have a PPA (repo) with all downgrades and the driver itself including the binary blobs (which depend on the downgraded software) and the DRM driver (which is opensource) as DKMS package. So it gets build with every kernel release automatically.

If you haven't decided on a distribution I would recommend Ubuntu because of their launchpad.net page. If you still want keep working on Debian, I'm also fine with any contributions as long as they are not breaking support for Ubuntu.

Regards!

James-E-A commented 6 years ago

@thopiekar Actually, I attempted Ubuntu as my first choice; the reason I tried to compile the Debian packages manually is that the Ubuntu PPA is broken:

JamesTheAwesomeDude commented I was sadly unable to get @thopiekar's PPA working even on just a baseline Xenial Minimal Netinstall with Fluxbox. I see that the packages are still technically being compiled..for even as recent as Artsy...

and my thoughts were, that perhaps it would be easier to try to get things working with Debian since it's less generally tampered-with. (But I actually don't quite know what I am doing with this.)

I actually do not much care whether I'm on Debian or Ubuntu or something else, so long as I can get VA-API as well as at least rudimentary OpenGL support! 😆 So whichever is the most feasible to maintain EMGD on is excellent for me, as long as I can run otherwise approximately modern software.

On Ubuntu 16.04, minimal XFCE desktop installation, after installing the PPA and emgd-driver, the X server does not work: there is a black screen when the EMGD driver is used; I can see the screen for one single frame if I switch to TTY7 and then back to TTY1~6, but it is not native resolution and vanishes immediately.

I would love to lend a hand in getting this working; are there any log files or such that I can provide that would be helpful? I have already sent the logs from (failed) compilation on Stretch, but I could reinstall Xenial (or another version, whatever's preferred; though it might be better to test on older editions rather than newer due to the weakness of the Atom Z520 and the distance between X.Org 1.9 and the target) and provide any needed information and/or run any needed tests.

James-E-A commented 6 years ago

I don't know if this is useful for you; but when I was on Fedora 14, even Intel's packages (F14/emgd-{bin,devel,gui}-3398-1.18.i586.rpm), even downloaded and installed directly from Intel, did not seem to work.

What did work, however, was however it is that this Timesys company has packaged it: They seem to have heavily repacked it compared to Intel's distribution (and whatever they did worked, importantly),

and so perhaps taking some inspiration from theirs for the Ubuntu packaging could be useful in fixing it?

thopiekar commented 6 years ago

As soon as you see "emgd" in lsmod and your Xorg is downgrade together with Mesa, then you are almost done. There are two example files for xorg.conf's, which work on most cases. There are basically two different chips out there. After testing both example files, one should work and then use Intels documentation, which I have here in the repo (I think) and then you can tweak the xorg.conf file. After that you should get good OpenGL support. Sometimes glitchy and also returning wrong OpenGL strings for some applications, so they are confused, but it is something you can work with. These bugs come from the binary blobs, so no chance to fix that. Only workaround is to add additional checks to your needed OpenGL software.

I think I even have these packages here in my repo. I'm unpacking them and repacking them into .deb packages.

James-E-A commented 6 years ago

Hmm..

I managed to get EMGD working on Xenial, at least:

The trick was, you have to download and execute the emgd-xorg-conf script (apparently it not only works, but is necessary, on the Acer AspireOne 751h) to create 10-emgd.conf, which makes everything function.

I would be interested still to find out why it does not work on Debian, since this chipset is slow and needs all the help it can get to run quickly; Ubuntu has a very long boot time

thopiekar commented 6 years ago

Haha, emgd-xorg-conf is probably one of the oldest, but most useful scripts I ever wrote 😄 Well, Ubuntu is based on Debian. You should better ask yourself instead: Which services and other apps are installed by Canonical, which are normally not installed on Debian 😉

Talkless commented 6 years ago

I managed to get EMGD working on Xenial, at least:

@JamesTheAwesomeDude Does 3D acceleration work?

James-E-A commented 6 years ago

@Talkless

I'm not sure. What logs would I use to check that?

My browser doesn't want to use it due to "unresolved driver issues", even with layers.acceleration.force-enabled=true, and I doubt there'd be something like Minecraft that could run well on this anyway as a test.

I don't seem to have been able to get VA-API working (it would be great to have that working on something other than XBMC..perhaps it would be nice to "shoot for the moon" with something like Alpine due to the 2GB ram limit), but I have been doing a bit of hacking to try to get my chipset added to emgd-xorg-conf.py so that at least external display management is usable (I'll send results once it's up and running properly. The hard part is making it work "well" with Intel's terrible interface displacing XRandR..)

Talkless commented 6 years ago

I'm not sure. What logs would I use to check that?

@JamesTheAwesomeDude try running glxgears -info, it it prints (at the top) that it uses LLVM, it probably leans it's using software rasterizer, not hardware for OpenGL.

Also, while glxgears is running, try sudo perf top (you might need to install linux-perf-) package), and if you see that some (most?) of the time is spent within swrast_dri.so, that also means that it's software OpenGL renderer.

Additionaly, Xorg.log can also say it's sofware render:

$ fgrep -e DRI -e GLX -e EE /var/log/Xorg.0.log
[    22.164] (II) glamor: EGL version 1.4 (DRI2):
[    22.168] (EE) modeset(0): glamor initialization failed
[    22.817] (II) AIGLX: Screen 0 is not DRI2 capable
[    22.817] (EE) AIGLX: reverting to software rendering
[    22.822] (II) IGLX: enabled GLX_MESA_copy_sub_buffer
[    22.824] (II) IGLX: Loaded and initialized swrast
[    22.825] (II) GLX: Initialized DRISWRAST GL provider for screen 0