Thanks to bug 235310, I'm the new maintainer (upstream) for read-edid. I've changed the files inside the package to reflect this change of ownership, and I've applied the two gentoo patches (to build parse-edid on multiple archs and my own linux-2.6.26 patch) so far. Ebuild with the correct information for 1.4.2 to be attached. Builds and runs on amd64 and x86.
Created attachment 163768 [details] read-edid-1.4.2 ebuild fixes linux-2.6.26 build problems as well as the arch patch in portage already. Also reflects new maintainer (me) and the new website.
Good for you! Assigning to ebuild maintainers.
Please bump to 2.0.0 (same ebuild should work, except 2.0.0 depends on libx86). New version builds and runs on x86, amd64, and possibly others (testing, anyone?)... and not just parse-edid, get-edid works too. actual ebuild coming shortly.
Created attachment 166014 [details] 2.0.0 ebuild ebuild works for me... I may have screwed something up, given that I'm not an ebuild wizard.
Created attachment 166726 [details, diff] read-edid-2.0.0.ebuild.diff changed dependency to >=dev-libs/libx86-1.1-r1, 0.99 doesn't seem to work on amd64.
Committed
(In reply to comment #5) > Created an attachment (id=166726) [edit] > read-edid-2.0.0.ebuild.diff > > changed dependency to >=dev-libs/libx86-1.1-r1, 0.99 doesn't seem to work on > amd64. > and libx86 0.99 is the only one in amd64... the higher ones are in ~amd64. either keyword this or unkeyword that. Leave 1.4.1-r2 as unkeyworded, tho.
Both are ~amd64
Since version 1.4.2 did not even install the binary (get-edid), and therefore was useless, I unmasked and tried version 2.0.0-r1 and at least it seems to install the binary. So version 1.4.2 should be removed from portage.
Actually version 2.0 fails to install the other binary (parse-edid, which version 1.4 actually installed). So either way, one of the binaries is missing.
(In reply to comment #10) > Actually version 2.0 fails to install the other binary (parse-edid, which > version 1.4 actually installed). So either way, one of the binaries is missing. > If my memory serves, get-edid doesn't build on non-x86 and 1.4. parse-edid stays around for the benefit of lm_sensors,, which seems to need it (at least, DEPPENDs on it). In 2.0, both binaries should build on amd64 at least, so not getting parse is a bug. Post more info (shouldn't be possible to not build, so likely portage messing this up for you.)
(In reply to comment #11) > In 2.0, both binaries should build on amd64 at least, so not getting parse is > a bug. Post more info (shouldn't be possible to not build, so likely portage > messing this up for you.) I found out what caused it. Version 1.4 put parse-edid in /usr/sbin. The upgrade to 2.0 removed that and put it in /usr/bin instead. But bash did not notice and still tried to execute it from /usr/sbin. Ctrl+D and starting the shell again helped. Now the problem is that the program fails to get the information (and I have no idea why): get-edid: get-edid version 2.0.0 Performing real mode VBE call Interrupt 0x10 ax=0x4f00 bx=0x0 cx=0x0 Function supported Call successful VBE version 300 VBE string at 0x11100 "NVIDIA" VBE/DDC service about to be called Report DDC capabilities Performing real mode VBE call Interrupt 0x10 ax=0x4f15 bx=0x0 cx=0x0 Function supported Call successful Monitor and video card combination does not support DDC1 transfers Monitor and video card combination does not support DDC2 transfers 0 seconds per 128 byte EDID block transfer Screen is not blanked during DDC transfer Reading next EDID block VBE/DDC service about to be called Read EDID Performing real mode VBE call Interrupt 0x10 ax=0x4f15 bx=0x1 cx=0x0 Function supported Call failed The EDID data should not be trusted as the VBE call failed Error: output block unchanged
