tkinter not recognizing screen resolution correctly

This should be the problem of DPI aware,Read this in MSDN official document.

In windows 10:You need to use SetProcessDpiAwareness(Or SetThreadDpiAwarenessContext),Try to use:

import tkinter as tkimport ctypesctypes.windll.shcore.SetProcessDpiAwareness(2) # your windows version should >= 8.1,it will raise exception.root = tk.Tk()width = root.winfo_screenwidth()height = root.winfo_screenheight()print(width,height)root.mainloop()

Requirements of SetProcessDpiAwareness

In Windows XP or 7,you need to use SetProcessDPIAware()

So all the code might be:

import tkinter as tkimport ctypestry:    ctypes.windll.shcore.SetProcessDpiAwareness(2) # if your windows version >= 8.1except:    ctypes.windll.user32.SetProcessDPIAware() # win 8.0 or less root = tk.Tk()width = root.winfo_screenwidth()height = root.winfo_screenheight()print(width,height)root.mainloop()

If you use tk.call('tk', 'scaling'),it is also okay.but when you use ImageGrab.grab((xxxx))(And those functions which need to pass the position argument),maybe it will get the wrong size.

Looking at the problem, it seems to be a defect in ms-windows, and tk not using the known workaround for it.

Looking at the source code for tk, in the file win/tkWinX.c the function TkWinDisplayChanged uses the windows API call GetDeviceCaps to get the screen width and height with the parameters HORZRES and VERTRES.

Unfortunately, this page states (emphasis mine):

Note GetDeviceCaps reports info that the display driver provides. If the display driver declines to report any info, GetDeviceCaps calculates the info based on fixed calculations. If the display driver reports invalid info, GetDeviceCaps returns the invalid info. Also, if the display driver declines to report info, GetDeviceCaps might calculate incorrect info because it assumes either fixed DPI (96 DPI) or a fixed size (depending on the info that the display driver did and didn’t provide). Unfortunately, a display driver that is implemented to the Windows Display Driver Model (WDDM) (introduced in Windows Vista) causes GDI to not get the info, so GetDeviceCaps must always calculate the info.

I would rephrase that as follows; "after windows Vista, display information from GetDeviceCaps is not to be trusted".

There there is this page about high-dpi displays.This page uses some other GetDeviceCaps values, LOGPIXELSX and LOGPIXELSY (the numbers of pixels per "logical inch" in x and y) to calculate the real window size.The "default" DPI that GetDeviceCaps seems to use is 96.

Look at this fragment of tk code from win/tkWinX.c, you can see that tk uses LOGPIXELSX and LOGPIXELSY to calculate the screen size in mm.

voidTkWinDisplayChanged(    Display *display){    HDC dc;    Screen *screen;    if (display == NULL || display->screens == NULL) {      return;    }    screen = display->screens;    dc = GetDC(NULL);    screen->width = GetDeviceCaps(dc, HORZRES);    screen->height = GetDeviceCaps(dc, VERTRES);    screen->mwidth = MulDiv(screen->width, 254,          GetDeviceCaps(dc, LOGPIXELSX) * 10);    screen->mheight = MulDiv(screen->height, 254,          GetDeviceCaps(dc, LOGPIXELSY) * 10);

This value seems to be used to calculate winfo_fpixels()So I think that if you use root.winfo_fpixels('1i') you will get a reliable DPI value.

So, try this:

import tkinter as tkroot = tk.Tk()width = root.winfo_screenwidth()height = root.winfo_screenheight()dpi = root.winfo_fpixels('1i')real_width = int(width * dpi / 96)real_height = int(height * dpi / 96)print('real width should be', real_width)print('real height should be', real_height)

Edit A workaround is to set tkinter's scaling factor:

factor = dpi / 72root.tk.call('tk', 'scaling', factor)

I ran you code on my Raspberry pi, and got the correct value for my display (which is not a 4K display).

I do not have the solution, but I observe that the ratio between your expected/observed answers are

3840 / 1536 = 2.52160 / 864 = 2.5

Maybe the screen driver for a 4K display makes a difference between real physical pixels (3840x2160) and some concept of "logical pixels". The purpose would be to avoid some software to display, for example, a 8-point text with 8 real physical pixels, since that would be unreadable.

I cannot test this (I do not have the hardware), it is only a hypothesis. I also may not have the exact terminology.

(BTW, on iOS there are the concepts of points vs pixels--you can search for these terms. Even if it doesn't answer your problem, it may be a similar problem).