Re: [e-users] Having issues getting mixxx to work

[Φ SNAKΣ ΣYΣZ Φ]

I seem to recall when I originally got lost down this rabbit hole there 
were high DPI related issues with some QT apps.  I think an xorg-server 
change/fix affected things as well - think Xorg used to set everything 
to 96dpi;



https://www.mail-archttps://www.mail-archive.com/xorg@lists.x.org/msg06880.htmlhive.com/x...@lists.x.org/msg06880.html 



/"DMX DDX has been removed. - X server now correctly reports display 
DPI in more cases. This may affect //
//rendering of client applications that have their own workarounds for 
hi-DPI screens."/



Looks like some things may improve with QT6;


https://doc.qt.io/qt-6/highdpi.html


...or perhaps the fun will start all over again with everything looking 
wrong and we'll all need to find more workarounds :)



On 13/03/2023 14:34, Carsten Haitzler wrote:

On Sun, 12 Mar 2023 23:57:49 + (UTC) Anna Cassar via enlightenment-users
  said:


  Hi all,  First of all thank you all so much for your helpful replies. My
apologies, my knowledge of how QT apps render is not great yet, but I'm
certainly learning a lot more about it which is really useful! I've done a
bit more testing, and I'm also convinced now that if E has anything at all to
do with the issue then it's probably environment variable related (although I
haven't yet found a guide to help me check whether I have the GTK style
plugins fully installed and set up for E yet). I'm pleased to say that with
your help I was able to get Mixxx to work under Enlightenment!   I thought
I'd share details of my tests here in case they are helpful. QT apps appear
to be being given an incorrect device pixel ratio within Enlightenment. I've

e doesn't give any ratios... unless you mean ythe xsettings and xrdb xft.dpi
settings and there are noty incorrect settings here. it's a number that affects
scaling - anything renders to a dpi. e sets this to get apps to scale based on
your scale preferences. the goal is to have everyone consistent. that means
font X at size Y (eg Sans 10) draws the same everywhere. e sets dpi
appropriately to have this happen. if that dpi causes some apps to mis-render,
then the problem lies with that app and its toolkit.

if i tell you "you have a very low res TV very close to you so it have things
sized well i want you to use 50dpi" then... you do that. you use the dpi given
if that is how you scale things. this is what e does. it does seem some apps
just have never been tested with various dpi values and fall apart. that
doesn't make it an e bug - it makes it an app or toolkit bug where it just
can't handle some dpi that is given.

efl itself doesn't use dpi at all - it does not care. it does tell freetype
when rendering a font to use 75dpi because that is the old school dpi that was
commonly used when i started writing the font engine for evas, thus "sand 10"
in evas and in x would generally look the same. efl doesn't use dpi for scaling
- it relies on being given a scale factor. this is used to just go multiple
sizes of things, including font size internally as well as size of other items
marked to scale. so scale 0.5 means "draw things 1.2 the size as normal" or
scale = 2.0 == "draw it 2x the size" or scale 1.378 = draw it 37.8% bigger than
the default standard size. qt also supports this kind of scaling - gtk though
does not. or more specifically gtk does but ONLY integers. 1x, 2x, 3x. 4x. gtk
does not handle fractional scaling (it's been something gtk is working to fix i
understand), thus e sets dpi to try force fonts at least to match.

but again - this is an app or toolkit bug if it can't handle a given dpi (of
course assuming the dpi is sane = setting a dpi of 1 or 0 or 1993204 is probably
a bug).


only been able to test this against an old KDE install on a different machine
so far, with an older version of QT; Mixxx dialogs display without issue
there, but this might be unrelated. This problem only affects apps which set
HighDpiScaleFactorRoundingPolicy to PassThrough (such as Mixxx and QT's
DprGadget), and those apps display perfectly when
QT_SCALE_FACTOR_ROUNDING_POLICY=Round is set as an environment variable
(setting QT_SCALE_FACTOR=1.0 results in no change).   Within Enlightenment,
Xorg.0.log shows my monitor's DPI defined as (90,88) which is correct;

aaah e doesn't set dpi to the correct value. as above. the only way to get gtk
AND qt to both scale in  any sensible way is to set the dpi to something to
make it scale. of course SETTING dpi is wrong, but the older toolkits and apps
have it in their head that this is how you scale - you fake the dpi. to me the
dpi is a fixed property of a display device and does not change - never should
change. it's used only when you want to specifically draw something at a
physical size on that display. buty... that's now how these older toolkits
think.


xdpyinfo shows 90x88 DPI in resolution; and xrdb shows Xft.dpi as 90 

Re: [e-users] Having issues getting mixxx to work

[Carsten Haitzler]

On Sun, 12 Mar 2023 23:57:49 + (UTC) Anna Cassar via enlightenment-users
 said:

>  Hi all,  First of all thank you all so much for your helpful replies. My
> apologies, my knowledge of how QT apps render is not great yet, but I'm
> certainly learning a lot more about it which is really useful! I've done a
> bit more testing, and I'm also convinced now that if E has anything at all to
> do with the issue then it's probably environment variable related (although I
> haven't yet found a guide to help me check whether I have the GTK style
> plugins fully installed and set up for E yet). I'm pleased to say that with
> your help I was able to get Mixxx to work under Enlightenment!   I thought
> I'd share details of my tests here in case they are helpful. QT apps appear
> to be being given an incorrect device pixel ratio within Enlightenment. I've

e doesn't give any ratios... unless you mean ythe xsettings and xrdb xft.dpi
settings and there are noty incorrect settings here. it's a number that affects
scaling - anything renders to a dpi. e sets this to get apps to scale based on
your scale preferences. the goal is to have everyone consistent. that means
font X at size Y (eg Sans 10) draws the same everywhere. e sets dpi
appropriately to have this happen. if that dpi causes some apps to mis-render,
then the problem lies with that app and its toolkit.

if i tell you "you have a very low res TV very close to you so it have things
sized well i want you to use 50dpi" then... you do that. you use the dpi given
if that is how you scale things. this is what e does. it does seem some apps
just have never been tested with various dpi values and fall apart. that
doesn't make it an e bug - it makes it an app or toolkit bug where it just
can't handle some dpi that is given.

efl itself doesn't use dpi at all - it does not care. it does tell freetype
when rendering a font to use 75dpi because that is the old school dpi that was
commonly used when i started writing the font engine for evas, thus "sand 10"
in evas and in x would generally look the same. efl doesn't use dpi for scaling
- it relies on being given a scale factor. this is used to just go multiple
sizes of things, including font size internally as well as size of other items
marked to scale. so scale 0.5 means "draw things 1.2 the size as normal" or
scale = 2.0 == "draw it 2x the size" or scale 1.378 = draw it 37.8% bigger than
the default standard size. qt also supports this kind of scaling - gtk though
does not. or more specifically gtk does but ONLY integers. 1x, 2x, 3x. 4x. gtk
does not handle fractional scaling (it's been something gtk is working to fix i
understand), thus e sets dpi to try force fonts at least to match.

but again - this is an app or toolkit bug if it can't handle a given dpi (of
course assuming the dpi is sane = setting a dpi of 1 or 0 or 1993204 is probably
a bug).

> only been able to test this against an old KDE install on a different machine
> so far, with an older version of QT; Mixxx dialogs display without issue
> there, but this might be unrelated. This problem only affects apps which set
> HighDpiScaleFactorRoundingPolicy to PassThrough (such as Mixxx and QT's
> DprGadget), and those apps display perfectly when
> QT_SCALE_FACTOR_ROUNDING_POLICY=Round is set as an environment variable
> (setting QT_SCALE_FACTOR=1.0 results in no change).   Within Enlightenment,
> Xorg.0.log shows my monitor's DPI defined as (90,88) which is correct;

aaah e doesn't set dpi to the correct value. as above. the only way to get gtk
AND qt to both scale in  any sensible way is to set the dpi to something to
make it scale. of course SETTING dpi is wrong, but the older toolkits and apps
have it in their head that this is how you scale - you fake the dpi. to me the
dpi is a fixed property of a display device and does not change - never should
change. it's used only when you want to specifically draw something at a
physical size on that display. buty... that's now how these older toolkits
think.

> xdpyinfo shows 90x88 DPI in resolution; and xrdb shows Xft.dpi as 90 (set
> in .Xdefaults) so I _think_ these are all as they should be. However,
> DprGadget shows a device pixel ratio of 0.9375 (which is 90/96), and all
> other widgets are not displayed at all! This is the same problem I was seeing
> in Mixxx. If I set QT_SCALE_FACTOR=96/90, DprGadget _does_ work well, and
> displays a device pixel ratio of 1.0, along with a native logical DPI of 90,
> but, oddly, a QWindow DPI of 96! If the pixel ratio within QT under

i suspect this rounding feature might be like rounding down? and thus a dpi
like 90/96 rounds down to 0 by qt and thus falls apart totally. thus would be a
qt bug though... :)

> Enlightenment is based on a DPI of 96, alongside the correct DPI of 90 for my
> system, I've no idea at all yet where that's coming from. Within plain X,
> xrdb returns _nothing_ under xterm, and xdpyinfo still shows 90x88 DPI.

e sets both xft.dpi xrdb and xsettings 

Re: [e-users] enlightenment audio default device issue

[Massimo Maiurana]

Masaru Nomiya ha scritto il 12/03/23 alle 07:31:

Hello,

野宮です．

In the Message;

   Subject: Re: [e-users] enlightenment audio default device issue
   Message-ID : <18d4e5ec-0b7e-69d7-5721-6338ff9ad...@gmail.com>
   Date & Time: Sat, 11 Mar 2023 14:22:58 +0100

[MM] == Massimo Maiurana  has written:

MM>  Masaru Nomiya ha scritto il 11/03/23 alle 11:20:

MN>> What the hell is that supposed to mean?

MM>  Sorry, my bad, the package that asked to remove pulseaudio was
MM>  pipewire-media-session. pipewire-alsa is now installed as you can see:

MM>  max@diamante:~$ apt list --installed | grep pipewire
MM>  gstreamer1.0-pipewire/testing,now 0.3.65-3 amd64 [installato, automatico]
MM>  libpipewire-0.3-0/testing,now 0.3.65-3 amd64 [installato, automatico]
MM>  libpipewire-0.3-common/testing,testing,now 0.3.65-3 all [installato, 
automatico]
MM>  libpipewire-0.3-modules/testing,now 0.3.65-3 amd64 [installato, automatico]
MM>  pipewire-alsa/testing,now 0.3.65-3 amd64 [installato]
MM>  pipewire-audio/testing,testing,now 0.3.65-3 all [installato, automatico]
MM>  pipewire-bin/testing,now 0.3.65-3 amd64 [installato, automatico]
MM>  pipewire-libcamera/testing,now 0.3.65-3 amd64 [installato]
MM>  pipewire-pulse/testing,now 0.3.65-3 amd64 [installato, automatico]
MM>  pipewire/testing,now 0.3.65-3 amd64 [installato, automatico]

My bad?

In the Message;

   Subject: Re: [e-users] enlightenment audio default device issue
   Message-ID : 
   Date & Time: Sat, 25 Feb 2023 23:01:18 +0100

[MM] == Massimo Maiurana  has written:

[...]
MM>  Oh, you're asking for installed packages then, not installed files. Here 
they
MM>  are:

MM>  apt list --installed | grep pipewire
MM>  gstreamer1.0-pipewire/testing,now 0.3.65-2 amd64 [installato, automatico]
MM>  libpipewire-0.3-0/testing,now 0.3.65-2 amd64 [installato, automatico]
MM>  libpipewire-0.3-common/testing,testing,now 0.3.65-2 all [installato, 
automatico]
MM>  libpipewire-0.3-modules/testing,now 0.3.65-2 amd64 [installato, automatico]
MM>  pipewire-bin/testing,now 0.3.65-2 amd64 [installato, automatico]
MM>  pipewire-pulse/testing,now 0.3.65-2 amd64 [installato, automatico]
MM>  pipewire/testing,now 0.3.65-2 amd64 [installato, automatico]

MM>  apt list --installed | grep pulse
MM>  gstreamer1.0-pulseaudio/testing,now 1.22.0-dmo2 amd64 [installato]
MM>  libcanberra-pulse/testing,now 0.30-10 amd64 [installato]
MM>  libpulse-dev/testing,now 16.1+dfsg1-2+b1 amd64 [installato]
MM>  libpulse-mainloop-glib0/testing,now 16.1+dfsg1-2+b1 amd64 [installato,
MM>  automatico]
MM>  libpulse0/testing,now 16.1+dfsg1-2+b1 amd64 [installato, automatico]
MM>  libpulsedsp/testing,now 16.1+dfsg1-2+b1 amd64 [installato, automatico]
MM>  pipewire-pulse/testing,now 0.3.65-2 amd64 [installato, automatico]
MM>  pulseaudio-module-bluetooth/testing,now 16.1+dfsg1-2+b1 amd64 [installato]
MM>  pulseaudio-utils/testing,now 16.1+dfsg1-2+b1 amd64 [installato, automatico]
MM>  pulseaudio/testing,now 16.1+dfsg1-2+b1 amd64 [installato]


Yep, i did install it as you suggested but i answered about the wrong 
package, which i can't install as already said. It was not difficult to 
understand.




I can't take you anymore.


No problem, indeed your help led me nowhere.



Regards.

---
┏━━┓彡 野宮  賢 mail-to: nomiya @ lake.dti.ne.jp
┃＼／彡
┗━━┛  Think.
-- The IBM slogan --


___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users


___
enlightenment-users mailing list
enlightenment-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/enlightenment-users