• 1
  • 122
  • 123
  • 124(current)
  • 125
  • 126
  • 260
Intel NUC - Haswell (4th Generation CPU)
@lmyllari, use ceil on the result and compare with the correct division, if it's smaller epsilon -> use the ceil.

Code:
From 3eb236cd04dc43e0b5d3b26f421eb13eea2c6116 Mon Sep 17 00:00:00 2001
From: fritsch <[email protected]>
Date: Sun, 19 Jan 2014 00:56:07 +0100
Subject: [PATCH] WinSystemX11: Don't try to scale scale values near to 1.0f

---
xbmc/windowing/X11/WinSystemX11.cpp | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/xbmc/windowing/X11/WinSystemX11.cpp b/xbmc/windowing/X11/WinSystemX11.cpp
index 083d1e9..5a821fd 100644
--- a/xbmc/windowing/X11/WinSystemX11.cpp
+++ b/xbmc/windowing/X11/WinSystemX11.cpp
@@ -277,8 +277,13 @@ void CWinSystemX11::UpdateResolutions()
       res.iHeight = mode.h;
       res.iScreenWidth  = mode.w;
       res.iScreenHeight = mode.h;
-      if (mode.h>0 && mode.w>0 && out.hmm>0 && out.wmm>0)
+      if (mode.h > 0 && mode.w > 0 && out.hmm > 0 && out.wmm > 0)
+      {
         res.fPixelRatio = ((float)out.wmm/(float)mode.w) / (((float)out.hmm/(float)mode.h));
+        float ceilRatio = ceil(res.fPixelRatio);
+        if (fabs(ceilRatio - res.fPixelRatio) < 0.01)
+          res.fPixelRatio = ceilRatio;
+      }
       else
         res.fPixelRatio = 1.0f;

--
1.8.3.2

If difference between ceil and direct value < 0.01 use the ceil. E.g. 0.998f will be 1.0f
First decide what functions / features you expect from a system. Then decide for the hardware. Don't waste your money on crap.
Reply
(2014-01-18, 10:56)-DDD- Wrote: i haven't found any Documents or Reviews about this new NUC Type.

(2014-01-18, 12:14)niksus Wrote: Sure you can, that's the point of the "H" case.

Thanks Niksus and -DDD-, at worse if I can't fit a msata and hdd inside the "H" version, I will order the short version instead and plug my external HDD with usb but it' not what I prefer.
Reply
it explicitly mentions there are two pcie slots in addition to the sata port for that version, so i would assume so.
Reply
Can someone explain to me where the wmm and hmm variables are being populated from and what is their meaning?

From my xbmc-xrandr output (not on haswell hardware here, but I have the same issue with pixel ratios on my nvidia hardware, which I had so far worked around by editing the values to 1.0000 by hand in guisettings.xml)

<output name="DVI-I-2" connected="true" w="1920" h="1080" x="0" y="0" wmm="598" hmm="336">

The fact that 598/336 != 16/9 is obviously the underlying issue here, and I would like to understand where these numbers come from.

(2014-01-19, 01:42)fritsch Wrote: @lmyllari, use ceil on the result and compare with the correct division, if it's smaller epsilon -> use the ceil.

Code:
From 3eb236cd04dc43e0b5d3b26f421eb13eea2c6116 Mon Sep 17 00:00:00 2001
From: fritsch <[email protected]>
Date: Sun, 19 Jan 2014 00:56:07 +0100
Subject: [PATCH] WinSystemX11: Don't try to scale scale values near to 1.0f

---
xbmc/windowing/X11/WinSystemX11.cpp | 7 ++++++-
1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/xbmc/windowing/X11/WinSystemX11.cpp b/xbmc/windowing/X11/WinSystemX11.cpp
index 083d1e9..5a821fd 100644
--- a/xbmc/windowing/X11/WinSystemX11.cpp
+++ b/xbmc/windowing/X11/WinSystemX11.cpp
@@ -277,8 +277,13 @@ void CWinSystemX11::UpdateResolutions()
       res.iHeight = mode.h;
       res.iScreenWidth  = mode.w;
       res.iScreenHeight = mode.h;
-      if (mode.h>0 && mode.w>0 && out.hmm>0 && out.wmm>0)
+      if (mode.h > 0 && mode.w > 0 && out.hmm > 0 && out.wmm > 0)
+      {
         res.fPixelRatio = ((float)out.wmm/(float)mode.w) / (((float)out.hmm/(float)mode.h));
+        float ceilRatio = ceil(res.fPixelRatio);
+        if (fabs(ceilRatio - res.fPixelRatio) < 0.01)
+          res.fPixelRatio = ceilRatio;
+      }
       else
         res.fPixelRatio = 1.0f;

--
1.8.3.2

If difference between ceil and direct value < 0.01 use the ceil. E.g. 0.998f will be 1.0f
Reply
(2014-01-18, 15:12)micoba Wrote: Why didn't you disable WOL? That way at least it shuts down immeaditely, though, I miss a working standby.

When will Intel finally fix this? It's getting annoying!!!

Disabling WOL is no option for me since i wake the NUC only vial wake on lan..then i like it way better to shut down it twice...but with all nightlies r17xxx it keeps rebooting all time, the same for lmyllari patched build...no one else experiencing this..?
Reply
(2014-01-19, 01:34)philbio Wrote: My unit is fine in high end theater room, replace HDMI cable, check other cables and then RMA it.

Thanks, that's my best course of action. I'll replace the cables and report back.

(2014-01-19, 01:38)BLKMGK Wrote: HDMI output is digital, the noise you describe is analog. It's a cabling issue or maybe some sort of grounding issue IMO. I've not ever experienced this with either of the NUC I have even at high volumes.

Thanks BLKMGK, your exactly right regarding digital vs analog and thus my confusion on hearing the hum at all. Grounding issue is an interesting idea. I'll check that in addition to the cables.
Reply
(2014-01-19, 09:59)gamble Wrote: but with all nightlies r17xxx it keeps rebooting all time, the same for lmyllari patched build...no one else experiencing this..?
Yes, all nightlies r17xxx = pernament reboot.
OpenELEC-Generic (x86_64) r16865 = o.k.

(Intel NUC D34010WYK)
Reply
(2014-01-19, 09:59)gamble Wrote:
(2014-01-18, 15:12)micoba Wrote: Why didn't you disable WOL? That way at least it shuts down immeaditely, though, I miss a working standby.

When will Intel finally fix this? It's getting annoying!!!

Disabling WOL is no option for me since i wake the NUC only vial wake on lan..then i like it way better to shut down it twice...but with all nightlies r17xxx it keeps rebooting all time, the same for lmyllari patched build...no one else experiencing this..?

After a fresh install I also have the reboot problem.
To fix it I go to the bios chance noting and save and exit.
And the problem is cone, if I use the power button to wake up.
If I wake whit my harmony control.
The reboot problem is back. Confused
Reply
Maybe that's because of Kernel Update from 3.12 to 3.13?

6.1.2014 - r16865
8.1.2014 - linux: switch to linux-3.13 per default (except RPi)
https://github.com/OpenELEC/OpenELEC.tv/...56d9552dac
16.1.2014 - r17009
| myHTPC |
Reply
I have the NUC D34010WYK I'm having some issues, if I install openelec work fine audio with tv, but if plug to my avr not coming sound. If I install windows 7 and xbmc I got sound from avr but if I connect cec adapter if I turn off computer later i have to unplug the computer and plg back to have image back.


Anybody know how to fix those errors?


thanks
Reply
(2014-01-19, 01:42)fritsch Wrote: If difference between ceil and direct value < 0.01 use the ceil. E.g. 0.998f will be 1.0f
I'm not sure if I understood the code 100%, but wouldn't it fail if the direct value is too high, say 1.001f, or the desired ratio is not an integer?

(2014-01-19, 06:58)theMule Wrote: Can someone explain to me where the wmm and hmm variables are being populated from and what is their meaning?

From my xbmc-xrandr output (not on haswell hardware here, but I have the same issue with pixel ratios on my nvidia hardware, which I had so far worked around by editing the values to 1.0000 by hand in guisettings.xml)

<output name="DVI-I-2" connected="true" w="1920" h="1080" x="0" y="0" wmm="598" hmm="336">

The fact that 598/336 != 16/9 is obviously the underlying issue here, and I would like to understand where these numbers come from.
They are the display width and height in millimeters as reported from xrandr. I assume it gets the values from EDID.



edit: me no splel very good
Reply
I have the IR device working on opensuse 13.1. I discovered reading an intel forum (https://communities.intel.com/message/216302) that the BIOS has the device disabled after it is enabled. The solution posted was to do the following at boot time on Linux. I put these commands in the /etc/rc.d/boot.local file and IR started working.

modprobe -r nuvoton-cir
echo "auto" > /sys/bus/acpi/devices/NTN0530:00/physical_node/resources
modprobe nuvoton-cir
Reply
Ok. I think the point is that it's better to simply key on the pixel ratio being close to 1.0, rather than hardcode specific display aspects. (Otherwise you would also have to add 5/4, 16/10, 21/9, etc for more esoteric displays/computer monitors)

(2014-01-20, 05:42)lmyllari Wrote:
(2014-01-19, 01:42)fritsch Wrote: If difference between ceil and direct value < 0.01 use the ceil. E.g. 0.998f will be 1.0f
I'm not sure if I understood the code 100%, but wouldn't it fail if the direct value is too high, say 1.001f, or the desired ratio is not an integer?

(2014-01-19, 06:58)theMule Wrote: Can someone explain to me where the wmm and hmm variables are being populated from and what is their meaning?

From my xbmc-xrandr output (not on haswell hardware here, but I have the same issue with pixel ratios on my nvidia hardware, which I had so far worked around by editing the values to 1.0000 by hand in guisettings.xml)

<output name="DVI-I-2" connected="true" w="1920" h="1080" x="0" y="0" wmm="598" hmm="336">

The fact that 598/336 != 16/9 is obviously the underlying issue here, and I would like to understand where these numbers come from.
They are the display width and height in millimeters as reported from xrandr. I assume it gets the values from EDID.



edit: me no splel very good
Reply
(2014-01-20, 05:54)theMule Wrote: Ok. I think the point is that it's better to simply key on the pixel ratio being close to 1.0, rather than hardcode specific display aspects. (Otherwise you would also have to add 5/4, 16/10, 21/9, etc for more esoteric displays/computer monitors)
The only reason I don't like that is that if at some point in the future we'd like to use other than HD resolutions, like 720x480 to let display/processor handle scaling.

I think it would be better to avoid scaling by very small amounts.

There is a case to be made for special casing 4:3 and 16:9 - those are the aspect ratios of CEA standard modes. I do agree though that it's an ugly solution.
Reply
(2014-01-20, 05:53)frostie Wrote: I have the IR device working on opensuse 13.1. I discovered reading an intel forum (https://communities.intel.com/message/216302) that the BIOS has the device disabled after it is enabled. The solution posted was to do the following at boot time on Linux. I put these commands in the /etc/rc.d/boot.local file and IR started working.

modprobe -r nuvoton-cir
echo "auto" > /sys/bus/acpi/devices/NTN0530:00/physical_node/resources
modprobe nuvoton-cir

Look in the top right corner of this thread. There is a search box where you can enter keywords. This solution must have been posted a hundred times here.
Reply
  • 1
  • 122
  • 123
  • 124(current)
  • 125
  • 126
  • 260

Logout Mark Read Team Forum Stats Members Help
Intel NUC - Haswell (4th Generation CPU)7