none
UWP Monitor Helligkeit via HDMI via DCC/CI steuern RRS feed

  • Frage

  • Guten Tag

    Es gibt ein OpenSource Tool Namens Monitorian, mit welchem man die Helligkeit des Bildschirmes steuern kann. Dieses funktioniert soweit auch. Nun würde ich eine solche Funktion gerne in UWP nutzen. Allerdings weiss ich nicht genau, wie ich das ganze portieren / implementieren kann, da es scheinbar keine native API für UWP gibt. Die App wird nicht via Store vertrieben, nur via Sideload installiert, daher kann ich auch restricted capabilities usw. verwenenden. Kann mir bei diesem Problem jemand weiterhelfen? Wäre um jede noch so kleine Hilfe sehr dankbar.

    Mit freundlichen Grüssen

    Donnerstag, 22. Oktober 2020 07:07

Alle Antworten

  • Hallo Andi,

    die App macht dies über die Dxva2.dll wie hier zu sehen MonitorConfiguration. Das ist eine DirectX Komponente von MS. Sie ist z.B. unter Windows\System32 zu finden.

    Diese Datei solltest Du dir auch anschauen DdcMonitorItem

    Die Doku dazu findest Du hier Monitor Configuration


    Gruß Thomas
    13 Millionen Schweine landen jährlich im Müll
    Dev Apps von mir: UWP Segoe MDL2 Assets, UI Strings



    Donnerstag, 22. Oktober 2020 09:53
  • Hallo Thomas,

    Vielen Dank für deine Antwort. Ist denn eine solche Möglichleit in UWP überhaupt lauffähig? Irgdnwie blicke ich da nicht ganz durch. Das schlussendliche Ziel wäre es, das ganze unter Windows IoT Core zum laufen zu bekommen, falls darauf die Dxva2.dll auch vorhanden ist / angesteuert werden kann. 

    Mit freundlichen Grüssen

    Donnerstag, 22. Oktober 2020 10:16
  • Natürlich kann man auf C++ Libs aus UWP und C# oder VB.NET zugreifen. Man kann ja auch UWP Apps mit C++ entwickeln und alle Funktionen von DirectX direkt ansteuern. Mit C# könnte man dafür SharpDX nehmen.

    Die meisten APIs wenn es um die Hardware geht sind in C++ geschrieben. Die dann von MS für uns in C# zur Verfügung gestellt werden.

    Ob es mit dieser speziellen DLL Probleme gibt, weiß ich nicht. Kopiere die Klasse aus dem Projekt und probiere es einfach aus. Ich denke aber nicht das es Probleme geben wird. Ob das ganze unter Windows IoT Core laufen wird hängt davon ab ob die Backlight überhaupt ansteuerbar ist.


    Gruß Thomas
    13 Millionen Schweine landen jährlich im Müll
    Dev Apps von mir: UWP Segoe MDL2 Assets, UI Strings

    Donnerstag, 22. Oktober 2020 10:41
  • Habe die Klasse "DisplayConfiguration" jetzt mal ein mein Projekt kopiert und die Methode "SetMonitorBrightness" aufgerufen, dabei erhalte ich folgende Exception

    Exception thrown: 'System.ComponentModel.Win32Exception' in BrightnessControlTest.exe Windows API threw an error when changing brightness (0x5): Access denied

    Donnerstag, 22. Oktober 2020 13:04
  • Ich habe dies nun auch getestet und habe kein Access denied bekommen.

    Ich habe dann aber auch in diesem Zusammenhang eine andere Lösung gefunden. Es gibt doch APIs in UWP dafür die in Windows.Graphics.Display untergebracht sind. 

    Dieser Code erhöht die Heiligkeit meines Laptops auf 100%

    private void Button_Click(object sender, RoutedEventArgs e)
            {
                var disO = Windows.Graphics.Display.BrightnessOverride.GetForCurrentView();
                disO.SetBrightnessLevel(1, Windows.Graphics.Display.DisplayBrightnessOverrideOptions.UseDimmedPolicyWhenBatteryIsLow);
                disO.StartOverride();
            }

    Nach verlassen der Anwendung werden die Einstellungen wieder rückgängig gemacht.

    Bei meinem Monitor der am Laptop abgeschlossen ist funktioniert dies nicht da die Backlight scheinbar nicht verändert werden kann


    Gruß Thomas
    13 Millionen Schweine landen jährlich im Müll
    Dev Apps von mir: UWP Segoe MDL2 Assets, UI Strings


    Donnerstag, 22. Oktober 2020 14:50
  • Das Problem mit

    Windows.Graphics.Display.BrightnessOverride

    ist, dass dies scheinbar nur auf Laptop (Displays) funktioniert, bzw. auf Displays, welche auch direkt mit den Windows-Einstellungen die Helligkeit verändert werden kann. Wenn ich das "disO" - Objekt anschaue, oder mit

    bool supported = disO.IsSupported;

    prüfe, bekomme ich false zurück. Aus diesem Grund war mein nächster Gedanke, das ganze via DCC/CI zu steuern, da dies bei jedem unterstützten Monitor funktioniert.

    Funktioniert denn der Code von Monitorian bei dir zum ändern der Helligkeit?

    Mit freundlichen Grüssen

    Donnerstag, 22. Oktober 2020 15:00
  • Ich habe das ganze nun auch soweit getestet und leider bekomme ich nun auch kein zugriff. Ich habe auch ein paar capability gesetzt die mir sinnvoll erschienen gebracht hat dies aber nichts.

    Was aber geht ist der Aufruf aus eine ConsoleApp diese könnte man einfach aus UWP mit dem ProcessLauncher starten und Parameter übergeben

    Hier auch die Klasse 

    namespace Monitor
    {
        public class Ddc
        {
    		#region GetMonitorHandles
    
    		public static IntPtr[] GetMonitorHandles()
    		{
    			List<IntPtr> handleItems = new List<IntPtr>();
    
    			if (!EnumDisplayMonitors(
    				IntPtr.Zero,
    				IntPtr.Zero,
    				MonitorEnum,
    				IntPtr.Zero))
    			{
    				return null;
    			}
    
    			bool MonitorEnum(IntPtr hMonitor, IntPtr hdcMonitor, IntPtr lprcMonitor, IntPtr dwData)
    			{
    				handleItems.Add(hMonitor);
    				return true;
    			}
    
    			return handleItems.ToArray();
    		}
    
    		[StructLayout(LayoutKind.Sequential, CharSet = CharSet.Auto)]
    		public struct MONITORINFOEX
    		{
    			public uint cbSize;
    			public RECT rcMonitor;
    			public RECT rcWork;
    			public uint dwFlags;
    
    			[MarshalAs(UnmanagedType.ByValTStr, SizeConst = 32)]
    			public string szDevice;
    		}
    
    		[StructLayout(LayoutKind.Sequential)]
    		public struct RECT
    		{
    			public int left;
    			public int top;
    			public int right;
    			public int bottom;
    		}
    
    		#endregion
    
    		#region GetNumberOfPhysicalMonitorsFromHMONITOR
    
    		[DllImport("Dxva2.dll", SetLastError = true)]
    		[return: MarshalAs(UnmanagedType.Bool)]
    		public static extern bool GetNumberOfPhysicalMonitorsFromHMONITOR(
    			IntPtr hMonitor,
    			out uint pdwNumberOfPhysicalMonitors);
    
    		#endregion
    
    		#region GetPhysicalMonitorsFromHMONITOR
    
    		[DllImport("Dxva2.dll", SetLastError = true)]
    		[return: MarshalAs(UnmanagedType.Bool)]
    		public static extern bool GetPhysicalMonitorsFromHMONITOR(
    			IntPtr hMonitor,
    			uint dwPhysicalMonitorArraySize,
    			[Out] PHYSICAL_MONITOR[] pPhysicalMonitorArray);
    
    		[StructLayout(LayoutKind.Sequential, CharSet = CharSet.Auto)]
    		public struct PHYSICAL_MONITOR
    		{
    			public IntPtr hPhysicalMonitor;
    
    			[MarshalAs(UnmanagedType.ByValTStr, SizeConst = 128)]
    			public string szPhysicalMonitorDescription;
    		}
    
    		#endregion
    
    		#region EnumDisplayMonitors
    
    		[DllImport("User32.dll")]
    		public static extern bool EnumDisplayMonitors(
    			IntPtr hdc,
    			IntPtr lprcClip,
    			MonitorEnumProc lpfnEnum,
    			IntPtr dwData);
    
    		[return: MarshalAs(UnmanagedType.Bool)]
    		public delegate bool MonitorEnumProc(
    			IntPtr hMonitor,
    			IntPtr hdcMonitor,
    			IntPtr lprcMonitor,
    			IntPtr dwData);
    
    		#endregion
    
    		[DllImport("Dxva2.dll", SetLastError = true)]
    		[return: MarshalAs(UnmanagedType.Bool)]
    		public static extern bool SetVCPFeature(
    			SafePhysicalMonitorHandle hMonitor,
    			byte bVCPCode,
    			uint dwNewValue);
    	}
    
    	public class SafePhysicalMonitorHandle : SafeHandle
    	{
    		public SafePhysicalMonitorHandle(IntPtr handle) : base(IntPtr.Zero, true)
    		{
    			this.handle = handle; // IntPtr.Zero may be a valid handle.
    		}
    
    		public override bool IsInvalid => false; // The validity cannot be checked by the handle.
    
    		protected override bool ReleaseHandle()
    		{
    			return DestroyPhysicalMonitor(handle);
    		}
    
    		[DllImport("Dxva2.dll", SetLastError = true)]
    		[return: MarshalAs(UnmanagedType.Bool)]
    		public static extern bool DestroyPhysicalMonitor(
    			IntPtr hMonitor);
    	}
    
    	public static class Error
    	{
    		#region Win32
    
    		[DllImport("Kernel32.dll", SetLastError = true)]
    		private static extern uint FormatMessage(
    			uint dwFlags,
    			IntPtr lpSource,
    			uint dwMessageId,
    			uint dwLanguageId,
    			StringBuilder lpBuffer,
    			int nSize,
    			IntPtr Arguments);
    
    		private const uint FORMAT_MESSAGE_FROM_SYSTEM = 0x00001000;
    
    		#endregion
    
    		public static string GetMessage() => GetMessage(Marshal.GetLastWin32Error());
    
    		public static string GetMessage(int errorCode)
    		{
    			var message = new StringBuilder($"Code: {errorCode}");
    
    			var buffer = new StringBuilder(512); // This 512 capacity is arbitrary.
    			if (FormatMessage(
    				FORMAT_MESSAGE_FROM_SYSTEM,
    				IntPtr.Zero,
    				(uint)errorCode,
    				0x0409, // US (English)
    				buffer,
    				buffer.Capacity,
    				IntPtr.Zero) > 0)
    			{
    				message.Append($", Message: ").Append(buffer);
    			}
    
    			return message.ToString();
    		}
    	}
    }

    Und der Aufruf

    namespace ConsoleApp1
    {
        class Program
        {
            static void Main(string[] args)
            {
                Console.WriteLine("Hello World!");
    
                try
                {
                    var handels = Monitor.Ddc.GetMonitorHandles();
                    if (handels != null)
                    {
                        foreach (var item in handels)
                        {
                            if (Monitor.Ddc.GetNumberOfPhysicalMonitorsFromHMONITOR(item, out uint count))
                            {
                                var physicalMonitors = new Monitor.Ddc.PHYSICAL_MONITOR[count];
                                if (Monitor.Ddc.GetPhysicalMonitorsFromHMONITOR(item, count, physicalMonitors))
                                {
                                    if (physicalMonitors.Length > 0)
                                    {
                                        if (Monitor.Ddc.SetVCPFeature(new Monitor.SafePhysicalMonitorHandle(physicalMonitors[0].hPhysicalMonitor), 0x10, 50) == false)
                                        {
                                            var err = Monitor.Error.GetMessage();
                                        }
                                    }
                                }
                            }
                        }
                    }
                }
                catch (Exception ex)
                {
                    var m = 123;
                }
            }
        }
    }


    Gruß Thomas
    13 Millionen Schweine landen jährlich im Müll
    Dev Apps von mir: UWP Segoe MDL2 Assets, UI Strings

    Donnerstag, 22. Oktober 2020 19:40
  • Guten Morgen Thomas,

    Vielen Dank für dein Codebeispiel und die Erklärung! Habe das nun einmal bei mir getestet, auf meinem PC funktioniert das soweit bestens. Ich kenne mich mit ConsoleApps eigentlich gar nicht aus, da ich mich bisher ausschliesslich mit UWP beschäftigt habe. Da ist bereits das compilen ein wenig anders, habs jedoch hinbekommen. Via cmd habe ich dann ein ARM-Build mit folgendem Befehl erstellen können:

    dotnet publish -r win10-arm

    Hoffe das ist richtig so? Danach das Ausgabeverzeichnis auf mein Dragonboard / IoT Gerät kopiert und via remote Powershell gestartet. Allerdings wird die Helligkeit nicht geändert, weiss aber gerade nicht, wo der Fehler liegt. Eigentlich wollte ich die ConsoleApp direkt aus einer Test UWP Anwendung heraus aufrufen, ginge auch auf dem IoT Gerät praktischer zum testen, ich weiss aber nicht genau, wie und wo die ConsoleApp liegen muss im Projekt, damit ich die mit dem ProcessLauncher aufrufen kann, hättest du mir da einen Tipp?

    Mit freundlichen Grüssen

    Freitag, 23. Oktober 2020 06:47
  • Hallo Andy,

    Du kannst ConsoleApps auch veröffentlichen recktsklick > auf das Console Projekt > Publish. Du solltest die Console App auch debuggen können Debuggen einer App per Remotekonsole. Vielleicht siehst Du dann was anders ist. MS schlägt auch eine etwas anderes vorgehen vor Using the Low-Level Monitor Configuration Functions

    Auf meinen IoT ist eigentlich nur noch Linux und ASP.NET Core. Deswegen habe ich aktuell auch keine Hardware mit der ist dies selbst testen könnte.

    Wohin Du die Console App kopierst ist ja egal hauptsache Du hast zugriff darauf


    Gruß Thomas
    Suche .NET Dev Job - Teilzeit 3 Tage die Woche
    Github

    Freitag, 23. Oktober 2020 11:48
  • Beim Veröffentlichen habe ich unter "Target Runtime" allerdings kein ARM zur Auswahl.

    Das mit dem Remote-Debuggen teste ich gleich einmal. Der durch MS vorgeschlagene Weg wäre ja noch eine andere Möglichkeit, grundsätzlich funktioniert aber der Code ja.

    Was ich allerdings nicht ganz verstehe ist, wie man den externen Prozess starten kann. Der Aufruf

    ProcessLauncher.RunToCompletionAsync
     

    Benötigt zwei Overloads, einmal "fileName" und einmal "args", beide als String. Wenn ich jedoch als fileName den Pfad zur exe der ConsoleApp einfüge, erhalte ich beim Ausführen am PC

    System.UnauthorizedAccessException: 'Zugriff verweigert (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))'

    Oder funktioniert das nur am IoT Gerät, da als Capability "systemManagement" benötigt wird?

    Freitag, 23. Oktober 2020 12:27
  • Du hast bei er Veröffentlichung auch Any CPU ausgewählt. Du kannst dies auf ARM ändern oder auch so lassen.

    Du muss noch etwas mehr tun um den ProcessLauncher zu nutzen. Ein ausführliche Anleitung findest Du hier ProcessLauncher.RunToCompletionAsync Method soweit ich mich erinnere funktionier das ganze nur unter IoT


    Gruß Thomas
    Suche .NET Dev Job - Teilzeit 3 Tage die Woche
    Github

    Freitag, 23. Oktober 2020 13:59
  • Okay muss ich mir gleich nochmal genauer anschauen.

    To launch a process the .exe must either be contained in the .appx package or be registered in the whitelist for this API.

    Hm also dann wäre es eine Möglichkeit, die ConsoleApp diurekt in die UWP App reinzupacken, damit dies geht? Was braucht es denn dazu? Bzgl. dem Aufruf steht auf der Seite leider auch nicht wirklich was, nur fileName, aber nichts bzgl. Pfad.


    Freitag, 23. Oktober 2020 14:53
  • Klar Du könntest die exe oder ein Zip mit in die eingebetteten Ressourcen ablegen und beim Start in deinen LocalFolder Ordner schreiben oder entpacken, sollte sie noch nicht vorhanden sein. Du könntest die exe aber auch in die Whitelist mit aufnehmen.

    Soweit ich mich erinnere muss der Path mit angegeben werden. Z.B. so:

    var file = await Windows.Storage.ApplicationData.Current.LocalFolder.GetFileAsync("meine.exe");
    await Windows.System.ProcessLauncher.RunToCompletionAsync(file.Path, "");



    Gruß Thomas
    Suche .NET Dev Job - Teilzeit 3 Tage die Woche
    Github

    Freitag, 23. Oktober 2020 15:09
  • Werde ich testen, vielen Dank.

    Bzgl. der exe, ist dies normal, dass als ARM kompiliert, im publish Verzeichnis 219 Dateien (notwendig) sind, wohingegen wenn für x86 kompiliert, gerade einmal 8 Dateien vorhanden sind? Heisst ja, dass ich das komplette Paket, also alle Dateien, in ein Verzeichnis in meinem Projekt anfügen müsste, oder? Weil wenn ich das ganze im Projekt inkludiere, wäre das auch praktischer für eventuelle Updates als msixbundle.

    Hier noch ein Screenshot der Veröffentlichungseinstellungen

    Da habe ich nur Any CPU zur Auswahl. Muss ich da noch etwas nachinstallieren? Wäre natürlich praktischer, auch für ARM direkt aus VS heraus zu kompilieren.

    Freitag, 23. Oktober 2020 15:30
  • Ich habe die .NET Core 3.1 SDK installiert und bei mir sieht das ganze so aus

    Mit "Produce single file" wird dann auch nur eine Datei erzeugt. Diese ist aber gleich mal 60Mb groß bei diesem Beispiel. Das kommt daher das ich auch Self-contained eingestellt haben und die nötigen Komponenten des .NET Core Frameworks mit in der Datei enthalten sind. Eine Installation von .NET Core ist dann auf dem System nicht mehr erforderlich. Macht natürlich in diesem Fall weniger sinn da unter IoT .NET Core schon installiert ist. Es könnte dennoch sinnvoll sein wenn nur diese Console App ein andere Frameworkversion nutzen soll. Dass alle sollte man sich gut überlegen und im Einzelfall entscheiden.

    Mit .NET 5 kommt jetzt auch ARM 64 hinzu. Die ersten Tests zeigt jetzt schon teilweise eine Steigerungvon 70-80%


    Gruß Thomas
    Suche .NET Dev Job - Teilzeit 3 Tage die Woche
    Github


    Freitag, 23. Oktober 2020 15:50
  • Wenn ich meine ganzen CosnoleApp - Dateien direkt in meine UWP Solution reinnehme, funktioniert das ganze nicht, weiss nicht genau, wo der Fehler liegt, ich bekomme immer einen AccessDenied, obwohl der Pfad zur exe stimmt. Nun habe ich das ConsoleApp Projekt auf dem IoT Gerät einmal nach C:\Monitor kopiert und den Reg-Eintrag hinzugefügt. So funktioniert der ProcessLauncher ohne Fehler und im "ProcessLauncherResult" bekomme ich "Exit-Code 0", was wohl in Ordnung sein wird. Allerdings, wird die Helligkeit leider nicht verändert, wie auch schon beim direkten Aufruf der ConsoleApp aus der PowerShell heraus. Den RemoteDebugger kann ich iwie nicht anhängen, da ich das hier so in meiner VS 2017 Community nicht habe

    sZusammenfassend kann ich sagen, dass soweit alles eigentlich bereit sein müsste, aber die Displayansteuerung scheinbar irgendwo ein Problem hat, welche ich so direkt wohl nicht debuggen kann. Schade, so weit gekommen.

    Freitag, 23. Oktober 2020 17:08
  • Du könntest versuchen dich an den Prozess auf dem IoT dranzuhängen. Wie das geht ist z.B. hier beschrieben Remote Debugging .Net Core 2.0 on Windows 10 IoT

    Du musst dann aber in der Console App ein delay oder ein sleep hinzufügen damit Du jetzt hast dich an den Prozess zu hängen. Bevor die Funktion ausgeführt wird. Ich setze hier meist einen Wert zwischen 5-10 Sekunden ein. Zudem muss die Console App mit Debug gebaut worden sein. Unter Linux funktionier dies immer


    Gruß Thomas
    Suche .NET Dev Job - Teilzeit 3 Tage die Woche
    Github


    Freitag, 23. Oktober 2020 17:21
  • Danke dir Thomas. Werde ich Morgen gleich mal testen und dann berichten.

    Vielen lieben Dank schon einmal für die grosse Hilfe und die ganze Mühe, die du dir machst, weiss ich sehr zu schätzen! 😊

    Freitag, 23. Oktober 2020 17:32
  • So, das dranhängen an den Prozess mithilfe einem sleep hat soweit funktioniert, so kann ich den Code nun auch problemlos debuggen. Nun liegt das Problem hier schon am Anfang

    Die Variable "handels" ist hier null, somit wird da natürlich nichts mehr gemacht.

    Samstag, 24. Oktober 2020 07:04
  • Ich habe einen älteren Raspberry PI gefunden auch dem Windows laufen sollte. Ich schau mir das mal heute Abend an

    Gruß Thomas
    Suche .NET Dev Job - Teilzeit 3 Tage die Woche
    Github

    Samstag, 24. Oktober 2020 12:31
  • Vielen lieben Dank Thomas!
    Samstag, 24. Oktober 2020 13:27
  • Das scheint an der User32.dll zu liegen diese ist unter IoT Core viel kleiner und auch nicht am "richtigen" Ort. Ich denke mal das sie diese Funktionen einfach nicht bietet. Im Internet findest man wenig dazu nur die Aussage das sie nicht alle Funktionen unterstützt. Ich habe die Klasse auch etwas umgebaut um zu schauen ob eine Exception geworfen wird, leider auch nicht. Ich habe dann noch als letzten versuch die MonitorFromWindow function hinzugefügt. Aber auch diese gibt kein Handle zurück.

    An diesem Punkt weiß ich auch nicht weiter


    Gruß Thomas
    Suche .NET Dev Job - Teilzeit 3 Tage die Woche
    Github

    Samstag, 24. Oktober 2020 22:25
  • Hm diese hab ich gestern auch noch verglichen mit derjenigen, an meinem Win10 Rechner. Ich nehme einmal an, dass man diese nicht einfach von irgendwo nehmen kann?

    Was ich mich allerdings gerade frage ist, ob das eine Softwarelimitierung in IoT Core ist, sprich ob das ganze mit einer Linuxansteuerung, z.b. Raspbian / Debian oder ev auch Android funktionieren könnte? 

    Ich denke jetzt mal ganz weit... Der Controller vom Monitor hat 2 Eingänge, einmal HDMI und einmal VGA, am VGA könnte ich rein für den Command abzusetzen (z.B. basierend auf einen Helligkeitssensor), einen Pi Zero nehmen. Diesen könnte ich auch via serieller Verbindung vom IoT Core aus ansteuern, um die Werte zu schicken. Ich brauche einfach irgend eine Möglichkeit, die Helligkeit steuern zu können.

    Sonntag, 25. Oktober 2020 10:16
  • Es gab mal Tablets mit ARM und vollen Windows. Vielleicht könnte man von diesen die User32.dll nehmen.

    Mit Rasbian und einem Raspberry PI wird dies sicherlich funktionieren es gibt auch ein Projekt dazu ddcutil. Ich vermute aber das je Eingang eine separate Konfiguration möglich ist.

    Wieso gehst Du nicht ganz auf Linux? MS hat die Hardwareschnittstellen von UWP auch schon nach Linux portiert .NET Core IoT Libraries. Aktuell bekommt man einen Raspberry PI mit 2 4K Ausgängen und 8GB Ram für um die 70€.

    Wenn ich aktuell kein bock habe für ein weiters Device Code zu entwickeln, nehme ich mir einfach die meist fertigen Python Anwendungen und starte sie über Kommandozeile.

    Und ich darf alles auf diesem System, Einschränkungen gibt es nicht.


    Gruß Thomas
    Suche .NET Dev Job - Teilzeit 3 Tage die Woche
    Github

    Sonntag, 25. Oktober 2020 12:31
  • Hm das sind aber nicht die Geräte mit Windows RT oder? Oder meinst du die aktuelleren Windows on ARM Geräte? Da könnte man die User32.dll ja auch mal probieren, oder? Die Datei befindet sich an mehreren Pfaden, ich nehme an, dass es sich um diejenigen in "C:\Windows\System32\" handelt?

    Das kann natürlich auch sein, ich werde dies aber trotzdem einmal versuchen, ob dies pro Eingang festgelegt wird.

    Grundsätzlich wäre ich da nicht komplett abgeneigt. Mein Dragonboard 410c nutze ich primär aus dem Grund, da es hardwarebeschleunigte GPU unter Windows IoT Core unterstützt und somit meine GUI deutlich flüssiger läuft, als auf einem RPi. Die Frage ist für mich halt, wie ich möglichst den kompletten Code auf Linux bringe (UI aus XAML, sowie Code-Behind). Es handelt sich um ein relativ grosses Projekt, mit tausenden von Zeilen Code, welche diverse UWP API's, sowie die GPIO's ansprechen...

    Sonntag, 25. Oktober 2020 13:22
  • Windows 10 ist WinRT. Es soll aber bald auch ein neues Windows rauskommen Windows X. Dieses soll dann auf dem Surface Duo laufen. Die User32.dll muss halt für ARM sein. Du könntest versuchen ein eigenes Windows 10 zu bauen. Win IoT Core das mit dem Dashborad installiert wird ist ja nur eine freie Basis Version und darf nur für Prototypen verwendet werden. Wie das geht und ob dir dies etwas bringt, weiß ich nicht.

    Ich kenne deine App nicht und kann demnach nicht sagen wie umfangreich die Portierung sein wird. Du könntest dein System genauer beschreiben, dann kann ich sicherlich eine besser Einschätzung treffen Auf Xaml würde ich nicht mehr setzen sondern auf HTML/CSS. Nächstes Jahr mit .NET 6 kommt auch MAUI dann ist es möglich native Apps mit Blazor/Razor zu entwickeln. Die GPIO Ansteuerung ist fast identisch zu UWP. Ich setze aber auch nicht mehr auf native Apps. Ein 10" Android Tablet kostet genauso viel wie ein Touchscreen. Mit einem Tablet bin ich aber auch nicht Kabelgebunden und kann mein IoT von überall aus steuern. Dazu reich dann auch nur ein RPI Zero W den man für um die 20€ bekommt. Ob dir dies etwas bringt oder nicht, weiß ich nicht. Ich bin mit meiner Entscheidung sehr zufrieden und ganz ehrlich würde ich mir Linux niemals auf meinem Desktop installieren und habe immer versuch einen ganz große Bogen um Linux zu machen. Aber dafür ist Linux für meine IoT optimal nur die Dokumentation lässt zu wünschen übrig.


    Gruß Thomas
    Suche .NET Dev Job - Teilzeit 3 Tage die Woche
    Github

    Sonntag, 25. Oktober 2020 15:54
  • Ich kann mal schauen, ob ich jemanden finde, der z.B. ein Windows on ARM Gerät besitzt und mit einer solchen User32.dll testen. Ev. betrifft das ganze auch noch die anderen im Code aufgerufenen dll-Dateien.

    Also es handelt sich grundsätzlich um ein eigenständiges Projekt, bzw. IoT Gerät mit Sensoren und eben einer Anzeige daran. XAML und UWP (C#) sind mir einfach sehr sympathisch und ich komme wirklich gut zurecht damit, finde das ganze sogar sehr angenehm. Aus diesem Grund würde ich auch gerne dabei bleiben, ausser eine Portierung wäre nicht der riesen Aufwand. 

    Bald soll ja scheinbar auch die neue IoT Variante kommen, habe ich in einem Channel9 Videoblogpost gesehen, was sich da dann genau ändert...

    Sonntag, 25. Oktober 2020 17:38
  • Ich habe mal eine eigene FFU hergestellt aber auch in dieser ist die selbe User32. Was Du aber noch versuchen könntest ist das Projekt "Windows 10 on Arm". Dabei wird ein volles Windows auf z.B. einen RPI installiert. Bei Heise gibt es dazu einen Artikel

    Du könntest auch versuchen direkt an die Display Driver von deinem DragonBoard zu gehen eine Beschreibung gibt es hier Display Drivers (ACPI and XML) Configuration Guide for Windows 10 IoT. Ich denke damit wirst Du am schnellsten zum Ziel kommen. Ich würde auch mal dort im Forum Fragen


    Gruß Thomas
    Suche .NET Dev Job - Teilzeit 3 Tage die Woche
    Github




    Sonntag, 25. Oktober 2020 19:24
  • Vielen Dank fürs testen! Ja von diesem Projekt habe ich auch schon gelesen, allerdings ist da die Performance nicht wirklich toll und damit verfehlt das ganze dann meine Idee.

    Ich habe herausgefunden, dass die Methode "EnumDisplayMonitors", welche bei mir "null" zurückgibt, tatsächlich in der "User32.dll" drin ist, wobei diese in Windows IoT Core wohl fehlt.

    Nun habe ich eine User32.dll von einem Windows on ARM Gerät, welche auf einem vollen Win10 in "C:\Windows\System32" liegt. In Windows IoT Core liegt diese aber in "C:\Windows\system32\Forwarders" und hier habe ich keine Berechtigung zum einfügen einer Datei (auch nicht via PowerShell). Wenn ich die User32.dll nach "C:\Windows\System32" kopiere, kann ich die App nicht mehr starten, da kommt dann

    ./BrightnessChanger.exe : Failed to load the dll from [C:\BrightnessChanger\coreclr.dll], HRESULT: 0x800700C1
        + CategoryInfo          : NotSpecified: (Failed to load ...ULT: 0x800700C1:String) [], RemoteException
        + FullyQualifiedErrorId : NativeCommandError
    
    Failed to bind to CoreCLR at 'C:\BrightnessChanger\coreclr.dll'
    Also wird sie zwar wohl eingelesen, aber verursacht ein Problem. Ob es aber daran liegt, dass im "Forwarders" - Verzeichnis auch noch eine liegt, kann ich so ja leider nicht testen.

    Montag, 26. Oktober 2020 17:23