https://wiki.archlinux.org/api.php?action=feedcontributions&user=Cges30901&feedformat=atomArchWiki - User contributions [en]2024-03-28T10:07:00ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Talk:Extreme_Multihead&diff=646057Talk:Extreme Multihead2020-12-20T09:23:50Z<p>Cges30901: Using an HDMI output:new section</p>
<hr />
<div>This is a first draft<br />
<br />
== Multihead Consolidation ==<br />
<br />
There already exist several attempts at documenting Multihead configuration each adding new perspectives but frequently repeating content from other pages (in different words)<br />
propose<br />
# providing an overview of X (and Multihead) configuration leading to detailed explanations<br />
# reduce the focus of individual pages to limit length, content duplication & complexity<br />
<br />
Possibly have composite pages address possible options and whys/wherefors -> how-to-pages with limited focus<br />
Sorry haven't time to pursue this right now (still building systems) - back soon [[User:Blacktav|Blacktav]] ([[User talk:Blacktav|talk]])<br />
:Well, I find there are many repeat pages too. Sorry I can only translate them to Chinese while my English is not good. Hope someone can get it done. -- [[User:Acgtyrant|Acgtyrant]] ([[User talk:Acgtyrant|talk]]) 10:18, 16 May 2013 (UTC)<br />
<br />
== dummy xorg driver ==<br />
<br />
<br />
<br />
I have never been able to make dummy xorg driver to work together with a real graphic card. Anyway, this is an example section that could be used. '''For me, this always resulted in xorg not starting or, worst, using the dummy device'''.<br />
<br />
You should probably also get the initial xorg configuration (Xorg -configure :2) and put it in anotehr file (es /etc/X11/xorg.conf.d/90-dummy.conf) adding the<br />
Option "primary" "true"<br />
Option "disable" "false"<br />
to the real physicial screen, to be sure that it is used. In this way, this dummy configuration should at least be harmless.<br />
<br />
<br />
{{hc|/etc/X11/xorg.conf.d/90-dummy.conf|<br />
Section "Monitor"<br />
Identifier "Monitor1"<br />
HorizSync 28.0-80.0<br />
VertRefresh 48.0-75.0<br />
Modeline "1920x1080_60.00" 172.80 1920 2040 2248 2576 1080 1081 1084 1118 -HSync +Vsync<br />
EndSection<br />
<br />
Section "Device"<br />
Identifier "Card1"<br />
Option "NoDDC" "true"<br />
Option "IgnoreEDID" "true"<br />
Driver "dummy"<br />
EndSection<br />
<br />
Section "Screen"<br />
DefaultDepth 16<br />
Identifier "Screen1"<br />
Device "Card1"<br />
Monitor "Monitor1"<br />
SubSection "Display"<br />
Depth 16<br />
Modes "1920x1080"<br />
EndSubSection<br />
EndSection<br />
<br />
Section "ServerLayout"<br />
Identifier "Main"<br />
Screen 0 "Screen0"<br />
Screen 1 "Screen1" rightof "Screen0" # assuming that the real screen is screen0<br />
Option "Xinerama" "1" # enable XINERAMA extension. Default is disabled.<br />
EndSection<br />
<br />
}}<br />
<br />
== Using an HDMI output ==<br />
Hello, in [[Extreme Multihead#Using an HDMI output]] section, it is mentioned that some programs will not recognize the screen, but I found a fix that works for me on my laptop with i5-4210M cpu. I am not sure if this will work for everyone.<br />
<br />
According to [[Kernel mode setting#Forcing modes]], you can set kernel parameter "video=<conn>:e" to force output. <conn> is connector name, you can find it with command<br />
for p in /sys/class/drm/*/status; do con=${p%/status}; echo -n "${con#*/card?-}: "; cat $p; done<br />
For my laptop the names for free outputs are "HDMI-A-1" and "VGA-1".<br />
<br />
-- [[User:Cges30901|Cges30901]] ([[User talk:Cges30901|talk]]) 17:21, 20 December 2020 (UTC)</div>Cges30901https://wiki.archlinux.org/index.php?title=Talk:Python_package_guidelines&diff=585934Talk:Python package guidelines2019-10-14T13:39:26Z<p>Cges30901: </p>
<hr />
<div>There is going to be an official policy drafted to deal with .pyc/.pyo files. See: https://wiki.archlinux.org/index.php/User:Allan/Python_Packaging_Policy<br />
<br />
== tests directory ==<br />
<br />
The article states that one shouldn't install a "tests" directory. My package however, after running through setup.py, contains such a directory. What is the recommended way to deal with this? Can this directory be deleted? Couldn't find a clue in other Python packages I've looked at, so can someone maybe point me in the right direction?<br />
<br />
: You should probably delete it from "${pkgdir}". I don't know of any reason to have such a directory, unless it contains unittests for the module. Which probably means upstream should be advised to fix their setup.py because there is no reason to run unittests on an installed module, and the module itself certainly shouldn't rely on methods hidden in the unittests...<br />
<br />
: I don't actually know of any misbehaving modules to point to which violate that rule though.<br />
: [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 18:52, 19 December 2016 (UTC)<br />
<br />
:: To the best of my knowledge, the recommendation is designed to prevent namespace conflicts. If I install your package and execute {{ic|python -c 'import tests'}}, and your code is imported, that's bad; If I install your package and execute {{ic|python -c 'from your_package import tests'}}, and your code is imported, that's fine. Getting this right is a little tricky. For an example of Python code that sidesteps these issues, see [https://github.com/PulpQE/pulp-smash/ this package]. The top-level "tests" directory is not — as of [https://github.com/PulpQE/pulp-smash/pull/458 this PR] — installed by setup.py, and therefore produces no namespace conflicts. The "pulp_smash/tests" directory is installed by setup.py and available as "pulp_smash.tests", and therefore produces no namespace conflicts. [[User:Ichimonji10|Ichimonji10]] ([[User talk:Ichimonji10|talk]]) 21:56, 19 December 2016 (UTC)<br />
<br />
:: I'm experiencing these issues with [https://aur.archlinux.org/packages/python-pendulum/ python-pendulum] and [https://aur.archlinux.org/packages/python-pytzdata/ python-pytzdata], both of which seem to install a global tests directory. Not too familiar with Python packaging, so I'm not sure if it is ok to simply delete those directories? --[[User:Johnpatcher|Johnpatcher]] ([[User talk:Johnpatcher|talk]]) 06:54, 20 December 2016 (UTC)<br />
<br />
== Python version directories ==<br />
For example debian packaging guidelines dictate that python files go into /usr/lib/pythonX/ and OpenSUSE wants files to go into /usr/lib/pythonX.Y/.<br />
<br />
Arch should have a clear guideline where packaged files go into. Most packages have their python files in /usr/lib/pythonX.Y/ but the package openimageio has python files in /usr/lib/python3/.<br />
<br />
[[User:Z3ntu|Z3ntu]] ([[User talk:Z3ntu|talk]]) 12:35, 24 January 2017 (UTC)<br />
<br />
:The {{ic|/usr/lib/python3/}} path does not work: {{bc|<nowiki><br />
>>> import sys<br />
>>> sys.path<br />
['', '/usr/lib/python36.zip', '/usr/lib/python3.6', '/usr/lib/python3.6/lib-dynload', '/home/lahwaacz/.local/lib/python3.6/site-packages', '/usr/lib/python3.6/site-packages']<br />
</nowiki>}} Hence it is a bug and should be reported on the bug tracker. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:46, 24 January 2017 (UTC)<br />
<br />
== Remove pip section in favor of wheels section? ==<br />
<br />
I can’t come up with any reason to use pip other than installing wheels, and wheels are just as easily installed by<br />
<br />
# Unzipping them into the {{ic|$pkgdir}}<br />
# Creating a little wrapper scripts for all console_scripts it provides (Which can be done manually or using {{AUR|install-wheel-scripts}})<br />
<br />
Do you agree? – [[User:Flying_sheep|flying sheep]] 18:08, 12 March 2019 (UTC)</div>Cges30901https://wiki.archlinux.org/index.php?title=Talk:Python_package_guidelines&diff=585708Talk:Python package guidelines2019-10-13T06:48:12Z<p>Cges30901: Python version in check</p>
<hr />
<div>There is going to be an official policy drafted to deal with .pyc/.pyo files. See: https://wiki.archlinux.org/index.php/User:Allan/Python_Packaging_Policy<br />
<br />
== tests directory ==<br />
<br />
The article states that one shouldn't install a "tests" directory. My package however, after running through setup.py, contains such a directory. What is the recommended way to deal with this? Can this directory be deleted? Couldn't find a clue in other Python packages I've looked at, so can someone maybe point me in the right direction?<br />
<br />
: You should probably delete it from "${pkgdir}". I don't know of any reason to have such a directory, unless it contains unittests for the module. Which probably means upstream should be advised to fix their setup.py because there is no reason to run unittests on an installed module, and the module itself certainly shouldn't rely on methods hidden in the unittests...<br />
<br />
: I don't actually know of any misbehaving modules to point to which violate that rule though.<br />
: [[User:Eschwartz|Eschwartz]] ([[User talk:Eschwartz|talk]]) 18:52, 19 December 2016 (UTC)<br />
<br />
:: To the best of my knowledge, the recommendation is designed to prevent namespace conflicts. If I install your package and execute {{ic|python -c 'import tests'}}, and your code is imported, that's bad; If I install your package and execute {{ic|python -c 'from your_package import tests'}}, and your code is imported, that's fine. Getting this right is a little tricky. For an example of Python code that sidesteps these issues, see [https://github.com/PulpQE/pulp-smash/ this package]. The top-level "tests" directory is not — as of [https://github.com/PulpQE/pulp-smash/pull/458 this PR] — installed by setup.py, and therefore produces no namespace conflicts. The "pulp_smash/tests" directory is installed by setup.py and available as "pulp_smash.tests", and therefore produces no namespace conflicts. [[User:Ichimonji10|Ichimonji10]] ([[User talk:Ichimonji10|talk]]) 21:56, 19 December 2016 (UTC)<br />
<br />
:: I'm experiencing these issues with [https://aur.archlinux.org/packages/python-pendulum/ python-pendulum] and [https://aur.archlinux.org/packages/python-pytzdata/ python-pytzdata], both of which seem to install a global tests directory. Not too familiar with Python packaging, so I'm not sure if it is ok to simply delete those directories? --[[User:Johnpatcher|Johnpatcher]] ([[User talk:Johnpatcher|talk]]) 06:54, 20 December 2016 (UTC)<br />
<br />
== Python version directories ==<br />
For example debian packaging guidelines dictate that python files go into /usr/lib/pythonX/ and OpenSUSE wants files to go into /usr/lib/pythonX.Y/.<br />
<br />
Arch should have a clear guideline where packaged files go into. Most packages have their python files in /usr/lib/pythonX.Y/ but the package openimageio has python files in /usr/lib/python3/.<br />
<br />
[[User:Z3ntu|Z3ntu]] ([[User talk:Z3ntu|talk]]) 12:35, 24 January 2017 (UTC)<br />
<br />
:The {{ic|/usr/lib/python3/}} path does not work: {{bc|<nowiki><br />
>>> import sys<br />
>>> sys.path<br />
['', '/usr/lib/python36.zip', '/usr/lib/python3.6', '/usr/lib/python3.6/lib-dynload', '/home/lahwaacz/.local/lib/python3.6/site-packages', '/usr/lib/python3.6/site-packages']<br />
</nowiki>}} Hence it is a bug and should be reported on the bug tracker. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 12:46, 24 January 2017 (UTC)<br />
<br />
== Remove pip section in favor of wheels section? ==<br />
<br />
I can’t come up with any reason to use pip other than installing wheels, and wheels are just as easily installed by<br />
<br />
# Unzipping them into the {{ic|$pkgdir}}<br />
# Creating a little wrapper scripts for all console_scripts it provides (Which can be done manually or using {{AUR|install-wheel-scripts}})<br />
<br />
Do you agree? – [[User:Flying_sheep|flying sheep]] 18:08, 12 March 2019 (UTC)<br />
<br />
== Python version in check ==<br />
<br />
According to this page, $PYTHONPATH hack is needed when checking for packages with compiled C extension. So I need to change this command when a new minor version of Python is released? Is there a way to avoid this?</div>Cges30901