Tiny Core Linux
Tiny Core Extensions => TCE Talk => Extension requests => Topic started by: pq5190362 on December 24, 2014, 04:59:44 PM
-
Hello,
as already mentioned over there:
http://forum.tinycorelinux.net/index.php/topic,17821.msg107521.html#msg107521
Could you please update the graphics stack in the 32-bit repo?
The 64-bit repo has (for example):
glamor-egl.tcz - 0.6.0
libvdpau.tcz - 0.8
xf86-video-ati.tcz - 7.5.0
xf86-video-intel.tcz - 2.99.916
xf86-video-vesa.tcz - 2.3.3
Xorg-7.7-3d.tcz - 10.3.2
xorg-server.tcz - 1.16.1
In comparison, the 32-bit repo only has:
glamor-egl.tcz - 0.5.0
libvdpau.tcz - 0.7
xf86-video-ati.tcz - 7.1.0
xf86-video-intel.tcz - 2.21.15
xf86-video-vesa.tcz - 2.3.2
Xorg-7.7-3d.tcz - 9.1.4
xorg-server.tcz - 1.14.2
So, it would be nice if you could update the graphics stack in the 32-bit repo for support of new GPUs / bugfixes / security fixes / new features / better performance and so on.
Regards
-
Hello,
anyone working on this or planning to work on it?
It would be much appreciated if someone could do it.
Regards
-
Maybe it would be better to wait until xf86-video-intel-3.00 is released.
-
Hello,
thanks four your reply.
Maybe it would be better to wait until xf86-video-intel-3.00 is released.
That sounds kinda reasonable.
But then again: What's wrong with xf86-video-intel 2.99.917 (the current version/snapshot) (http://lists.x.org/archives/xorg-announce/2014-December/002508.html)?
I mean, even the current Ubuntu release ships with a recent snapshot, see:
http://packages.ubuntu.com/utopic/xserver-xorg-video-intel
Can't you just update to xf86-video-intel 2.99.917 now and update to 3.0 later when it is released?
I mean, ideally it would be best to constantly update the graphics stack anyway (IMHO).
Or is building/updating the graphics stack that time consuming (honest question because I have no idea how much effort goes into updating the graphics stack)?
Regards
-
It takes perhaps 1-2 hours to build, plus added time for testing. Why not contribute if you need them?
-
Hello,
It takes perhaps 1-2 hours to build, plus added time for testing. Why not contribute if you need them?
well, I have thought about it. But at this point in time I am not a developer myself and it would probably take me quite a bit longer than two hours to learn how to do it (properly) ;).
And because I consider the graphics stack to be a core part of every distro and considering that juanito already seems to be the current maintainer of the graphics stack in both the 32-bit as well as the 64-bit repo, I thought it might be reasonable to ask ;).
Also I expected that the graphics stack would be updated when going from Core 5.x to 6.x (other distros update the graphics stack in new distro releases as well). But unfortunately it was only done for the 64-bit repo, which made me wonder why that is, so I asked.
juanito told me that it was done in the 64-bit repo only to support GNOME and because the 32-bit repo does not have GNOME it was not done in the 32-bit repo. (http://forum.tinycorelinux.net/index.php/topic,17821.msg107530.html#msg107530)
But surely there would also be other reasons to update the graphics stack (support of new GPUs / bugfixes / security fixes (http://www.phoronix.com/scan.php?page=news_item&px=MTg2OTc) / new features / better performance and so on)?
No offense, but, I do not quite get the "no GNOME, so no need to update the graphics stack" argument ;).
Regards
-
juanito told me that it was done in the 64-bit repo only to support GNOME...
More specifically, it was because I wanted to try out some of the gnome packages that required a more recent version of mesa.
It's a lot of work to update the numerous X-related packages. I mentioned waiting for xf86-video-intel-3.00 because the risk is that it will require a more recent version of xorg-server than is currently available, which in turn could mean updating a bunch of libs twice in a short space of time.
-
@pq5190362
While the X extensions are all interrelated, you could start with an easier target like libvdpau? It has relatively few dependencies and doesn't require updating anything else.
-
Hello,
It's a lot of work to update the numerous X-related packages. I mentioned waiting for xf86-video-intel-3.00 because the risk is that it will require a more recent version of xorg-server than is currently available, which in turn could mean updating a bunch of libs twice in a short space of time.
well, I can somehow understand that. But on the other hand, when looking at it from a security perspective for example, updating xorg-server ideally would have to be done constantly anyway.
Because, for example, this week upstream updated xorg-server again and it fixes yet another vulnerability, see:
http://www.phoronix.com/scan.php?page=news_item&px=X.Org-Server-1.17.1-Released
Both, the Core 32-bit as well as the 64-bit repos have older versions of xorg-server (1.14.2 for 32-bit and 1.16.1 for 64-bit), so I assume they still suffer from the vulnerabilites which were fixed with xorg-server 1.16.3 and then with xorg-server 1.17.1, which is why I think they should be updated anyway.
Well, I hope xf86-video-intel 3.0 will be released soon, so that you can update the graphics stack.
It would be much appreciated.
Regards
-
I really should mention that X security flaws don't really concern normal users. By default network access for X is disabled, nobody can use those remotely to hack you. If you run binary-only software, that software has much more convenient ways to hurt you.
-
I have the latest xorg-server working with the latest xf86-video-intel - give me a few days for the (somewhat tedious) task of checking the various extensions, recompiling all of the drivers and (best of all) updating the *info files...
-
That sounds good, do you know if they will they go into 6.1rc1 or will it be rc2 before we see them in a release?
-
6.0 -> 6.1 is an update to the base, xorg is a collection of extensions with nothing to do with the base
-
Hello,
I have the latest xorg-server working with the latest xf86-video-intel - give me a few days for the (somewhat tedious) task of checking the various extensions, recompiling all of the drivers and (best of all) updating the *info files...
thank you so much (in advance) Juanito! This is much appreciated. Really looking forward to it.
Regards
-
task of checking the various extensions, recompiling all of the drivers
PS:
I guess you would have done it anyway, but:
Could you please also update firmware-radeon.tcz when updating xf86-video-ati.tcz?
Regards
-
I'm not the maintainer of that extension - I sent a pm to the maintainer to request an update.
-
Thank you so much for the update (http://forum.tinycorelinux.net/index.php/topic,18070.0.html) Juanito!
I'm not the maintainer of that extension - I sent a pm to the maintainer to request an update.
Who is the maintainer of firmware-radeon.tcz?
Is it coreplayer2 (http://forum.tinycorelinux.net/index.php?action=profile;u=3262):
http://forum.tinycorelinux.net/index.php/topic,17393.0.html
?
-
I updated most the firmware packages some time back, am not sure if radeon firmware was part of that update... but I'll take a look at an update if possible later today
-
I'll take a look at an update if possible later today
That's nice, thanks in advance ;).
-
Hello,
any update regarding firmware-radeon.tcz?
Regards
-
Unfortunately I had difficulty finding an update for the radeon firmare from the sources link provided by the extension creator. However I think I may have found an update, so we'll see about an update in a couple more days.
-
Unfortunately I had difficulty finding an update for the radeon firmare from the sources link provided by the extension creator. However I think I may have found an update, so we'll see about an update in a couple more days.
How about this one:
http://people.freedesktop.org/~agd5f/radeon_ucode/
?
-
Hmmmm??
-
Hmmmm??
What do you mean with "Hmmmm??" ;)?
Isn't this:
http://people.freedesktop.org/~agd5f/radeon_ucode/
the radeon firmware?
-
I was suspicious of the address, but given who David Zeuthen and the lack of finding an official source I'll go ahead and update from the address provided. I'm assuming you have a Radeon card so I'll send you an updated extension to test in a few minutes
:)
-
I'm assuming you have a Radeon card
Not at the moment.
but given who David Zeuthen
Hmm? Where did you see a reference to "David Zeuthen"?
and the lack of finding an official source
I'm not entirely sure either if it is the correct thing for the firmware. But I have found a lot of references to it, see for example:
http://www.phoronix.com/forums/showthread.php?41135-Mandatory-component-for-Radeon-driver-on-zacate-e350&p=189395#post189395
http://lists.freedesktop.org/archives/dri-devel/2013-April/036766.html
http://people.freedesktop.org/~cbrill/dri-log/?channel=radeon&highlight_names=&date=2014-07-24
http://people.freedesktop.org/~cbrill/dri-log/?channel=radeon&highlight_names=&date=2014-07-06
http://people.freedesktop.org/~cbrill/dri-log/?channel=radeon&highlight_names=&date=2014-05-30
http://people.freedesktop.org/~cbrill/dri-log/?channel=radeon&highlight_names=&date=2014-05-07
;)
-
I'm assuming you have a Radeon card
Not at the moment.
pity, I just sent you an updated extension to try
but given who David Zeuthen
Hmm? Where did you see a reference to "David Zeuthen"?
within the link you provided
-
I'm assuming you have a Radeon card
Not at the moment.
pity, I just sent you an updated extension to try
Yeah, sorry, can't test right now.
But I also assumed that the maintainer of Radeon firmware would be in possession of Radeon hardware ;).
Maybe you could post the updated extension in a new thread in:
TCE Talk (http://forum.tinycorelinux.net/index.php/board,14.0.html)
or:
TCE News (http://forum.tinycorelinux.net/index.php/board,34.0.html)
and ask for testers there ;)?
-
I could help to test the firmware radeon, my tc6 x86 is up to date. But my hardware is an old ATI X1400 mobile. Please send me your tcz. Regards.
X.Org X Server 1.17.1
Release Date: 2015-02-10
[ 21.989] Build Operating System: Linux 3.16.6-tinycore i486
[ 21.989] Current Operating System: Linux box 3.16.6-tinycore #777 SMP Thu Oct 16 09:42:42 UTC 2014 i686
[ 21.989] Kernel command line: initrd=/boot/6/core.gz tce=sda3/tce6-32 blacklist=pcspkr keymap=azerty/fr-pc BOOT_IMAGE=/boot/6/vmlinuz
[ 21.989] Build Date: 13 February 2015 05:30:32PM
[ 22.011] (II) LoadModule: "radeon"
[ 22.011] (II) Loading /usr/local/lib/xorg/modules/drivers/radeon_drv.so
[ 22.029] (II) Module radeon: vendor="X.Org Foundation"
[ 22.029] compiled for 1.17.1, module version = 7.5.0
[ 22.054] (--) RADEON(0): Chipset: "ATI Mobility Radeon X1400" (ChipID = 0x7145)
[ 22.054] (II) Module "dri2" already built-in
-
Done
-
PS:
I was suspicious of the address, but given who David Zeuthen and the lack of finding an official source I'll go ahead and update from the address provided.
Quote from X.Org Wiki (http://www.x.org/wiki/radeonBuildHowTo/):
http://www.x.org/wiki/radeonBuildHowTo/
[...]
Missing Extra Firmware
All radeon gfxcards r600+ (r600 and higher) require extra firmware (ucode) files [1] to work properly with acceleration (Thanks agd5f for clarification on IRC). According to license issues [2] and the fact that no new firmware files will be shipped in upstream kernels, you need to activate the following kernel-config parameters:
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware"
CONFIG_EXTRA_FIRMWARE="radeon/CEDAR_me.bin radeon/CEDAR_pfp.bin radeon/CEDAR_rlc.bin radeon/CYPRESS_me.bin radeon/CYPRESS_pfp.bin radeon/CYPRESS_rlc.bin radeon/JUNIPER_me.bin radeon/JUNIPER_pfp.bin radeon/JUNIPER_rlc.bin radeon/R600_rlc.bin radeon/R700_rlc.bin radeon/REDWOOD_me.bin radeon/REDWOOD_pfp.bin radeon/REDWOOD_rlc.bin"
You can omit those firmware files for which you do not actually have hardware. Copy *.bin to /lib/firmware/radeon directory.
UPDATE: Extra ucode files are now in linux-firmware GIT repository [3] (Thanks airlied for information on IRC).
[1] http://people.freedesktop.org/~agd5f/radeon_ucode/
[2] http://people.freedesktop.org/~agd5f/radeon_ucode/LICENSE.radeon
[3] See commit d9076a54d74e371a11e1206b4a26e2e428045b9e "radeon: add RLC firmwares from AMD." (http://git.kernel.org/cgit/linux/kernel/git/firmware/linux-firmware.git/commit/?id=d9076a54d74e371a11e1206b4a26e2e428045b9e)
[...]
;)
-
For me, the new firmware-radeon.tcz has no negative/positive difference. Because the only file I need from tcz is R520_cp.bin which is the same size 2K and same calendar date 2014-01-02. The Xorg "works" with or without the binary blob.
Without firmware, "dmesg" shows:
[drm] Loading R500 Microcode
radeon 0000:01:00.0: Direct firmware load failed with error -2
radeon 0000:01:00.0: Falling back to user helper
radeon_cp: Failed to load firmware "radeon/R520_cp.bin"
[drm:r100_cp_init] *ERROR* Failed to load firmware!
radeon 0000:01:00.0: failed initializing CP (-12).
radeon 0000:01:00.0: Disabling GPU acceleration
[drm] radeon: cp finalized
and from "/var/log/Xorg0.lst":
[ 13.149] (--) RADEON(0): Chipset: "ATI Mobility Radeon X1400" (ChipID = 0x7145)
[ 13.149] (II) RADEON(0): GPU accel disabled or not working, using shadowfb for KMS
...
[ 13.889] (WW) RADEON(0): Direct rendering disabled
[ 13.889] (II) RADEON(0): Acceleration disabled
...
[ 13.893] (II) AIGLX: Screen 0 is not DRI2 capable
[ 13.893] (EE) AIGLX: reverting to software rendering
[ 13.919] (EE) AIGLX error: dlopen of /usr/local/lib/dri/swrast_dri.so failed (libelf.so.1: cannot open shared object file: No such file or directory)
[ 13.919] (EE) GLX: could not load software renderer
=====After firmware-radeon.tcz listed in /tce/onboot.lst and reboot=====
[ 13.259] (--) RADEON(0): Chipset: "ATI Mobility Radeon X1400" (ChipID = 0x7145)
[ 13.259] (II) Module "dri2" already built-in
[ 14.563] (II) RADEON(0): Render acceleration enabled for R300/R400/R500 type cards.
...
[ 14.036] (EE) AIGLX error: dlopen of /usr/local/lib/dri/r300_dri.so failed (libelf.so.1: cannot open shared object file: No such file or directory)
[ 14.036] (EE) AIGLX: reverting to software rendering
[ 14.036] (EE) AIGLX error: dlopen of /usr/local/lib/dri/swrast_dri.so failed (libelf.so.1: cannot open shared object file: No such file or directory)
[ 14.036] (EE) GLX: could not load software renderer
[ 14.036] (II) GLX: no usable GL providers found for screen 0
Hmm, the news are that a dependency is missing! Of course I could load it manually with tce-load -i elfutils.tcz
-
elfutils added to Xorg-7.7-3d deps - thanks
-
Hello,
any update regarding firmware-radeon.tcz?
Regards
-
Hello,
any update regarding firmware-radeon.tcz?
Regards
I believe an updated extension was posted to the repo long time ago, end of February..
:)
-
Ah, thank you very much :)!
-
Hello,
any update regarding firmware-radeon.tcz?
Regards
I believe an updated extension was posted to the repo long time ago, end of February..
:)
PS:
firmware-radeon.tcz (http://repo.tinycorelinux.net/6.x/x86/tcz/firmware-radeon.tcz) apparently is not up to date.
The following page:
http://people.freedesktop.org/~agd5f/radeon_ucode/
seems to have been updated in the meantime and therefore has some newer files compared to the current version of firmware-radeon.tcz (http://repo.tinycorelinux.net/6.x/x86/tcz/firmware-radeon.tcz).
So, could you please update firmware-radeon.tcz (http://repo.tinycorelinux.net/6.x/x86/tcz/firmware-radeon.tcz) again?
Regards
-
I've updated firmware-radeon with latest updates of 20th April 2015 & 11th May 2015
submitting...
-
I've updated firmware-radeon with latest updates of 20th April 2015 & 11th May 2015
submitting...
Thank you. But I noticed something:
First:
The info file has not been updated:
http://repo.tinycorelinux.net/6.x/x86/tcz/firmware-radeon.tcz.info
Second:
On this page:
http://people.freedesktop.org/~agd5f/radeon_ucode/
there are some subfolders containing files.
But in the extension:
http://repo.tinycorelinux.net/6.x/x86/tcz/firmware-radeon.tcz.info
the files from the subfolders have all been put into:
/usr/local/lib/firmware/radeon/
together with the other files.
So, now there seem to be duplicates of some files in that folder.
For example, there is:
BONAIRE_ce.bin (from 2014-01-02)
and there is:
bonaire_ce.bin (from 2015-05-23)
together in the same folder and so on...
Are you sure it's correct like this?
Regards
-
I'll look into the discrepancies
I'm not sure why the submitted info file was not the updated
I also see an opportunity to make the extension smaller with the duplicates, the extension is getting quite large now
-
pq5190362
The info file has not been updated
Actually I'm not sure what transpired with the info file because I'm looking at the new info file yet the old info file was somehow packaged with the updated firmware, will get it right this time thanks for spotting this
So, now there seem to be duplicates of some files in that folder.
For example, there is:
BONAIRE_ce.bin (from 2014-01-02)
and there is:
bonaire_ce.bin (from 2015-05-23)
together in the same folder and so on...
Are you sure it's correct like this?
yes there are duplicates, just as the upstream source has these duplicates.
The question we should be asking is: Are the older BONAIRE_ce.bin firmware blobs superseded by their lower case counterparts as in bonaire_ce.bin ?
If so, then why not replace the old firmware at source?? Both case versions have been included from source, therefore the driver must be searching for case sensitive firmware. I'm trying to see the logic.. I am also curious why separate newer firmware by case and sub-directory?? surely separation by name would have been appropriate??
I simply updated those files of matching case with their newer version, otherwise it's entirely possible for an original and two duplicates to exist as in the source
I'll inquire..
-
Official word from agd5f is to use the radeon subdir in the kernel-firmware git tree. His dir contains many old versions, and linux-firmware is always kept up to date.
-
Ah ha!
I've been reading up on the differences and it becomes quite complicated since they have attempted to support drivers provided in new kernels, additionally firmware currently supports Radeon and amdgpu hardware. At least AMD firmware is backwards compatible, apparently..
Thanks curaga, I think that's a good plan after all agd5f is the man on AMD. I'll grab the current firmware from kernel-firmware git tree and update..
Ref: http://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source-amd-linux/800259-amd-releases-open-source-vce-1-0-support/page2 (http://www.phoronix.com/forums/forum/linux-graphics-x-org-drivers/open-source-amd-linux/800259-amd-releases-open-source-vce-1-0-support/page2)
-
Yep, that's the post I meant. Nice googling!
-
Updated from kernel-firmware git tree clone and submitted.