Re: multiple gdm
Thanks, just to be clear, I don't want one gnome session running on two X servers. I want to run two different instances of gnome, each with its own X server. The idea would be, if all is working, when I boot my system, I'll get two gdm login screens, one for each monitor. I could then have to log in twice, perhaps under different user names. It may sound like a bad hack, but I'm just wondering if somehow I could configure gdm to work of some specified display, like :0.0 or :0.1 or something like that. On Thu, 2015-01-15 at 09:45 -0800, Jasper St. Pierre wrote: GNOME does not support multiple X11 screens. My understanding is that recent versions of nvidia proprietary added XRandR as a feature, which is what we require for multi monitor support. On Jan 15, 2015 6:31 AM, Stephen Adler ad...@stephenadler.com wrote: Guys, I'm not sure if this is the right mailing list to ask this question so forgive if I miss-posted... I have a system with two video cards, quadro K2200 and a K620 and the nvidia propriatary driver will not configure a single desktop (X server) using both cards. It will configure two separate X servers or X displays, one for each card. So I thought maybe I could run two versions of gdm, one for each X server or X display (I'm not sure the terminology here.) :0.0 and :0.1 would be the -display syntax to use. This way I could have two separate sessions a bit like a KVM switch expect I'd have two monitors with one keyboard and mouse, and I would move my mouse over from one monitor to another to switch from one gnome session to another. so... how would I configure gdm to run on two X displays or servers? Thanks! Steve. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: multiple gdm
GNOME does not support multiple X11 screens. My understanding is that recent versions of nvidia proprietary added XRandR as a feature, which is what we require for multi monitor support. On Jan 15, 2015 6:31 AM, Stephen Adler ad...@stephenadler.com wrote: Guys, I'm not sure if this is the right mailing list to ask this question so forgive if I miss-posted... I have a system with two video cards, quadro K2200 and a K620 and the nvidia propriatary driver will not configure a single desktop (X server) using both cards. It will configure two separate X servers or X displays, one for each card. So I thought maybe I could run two versions of gdm, one for each X server or X display (I'm not sure the terminology here.) :0.0 and :0.1 would be the -display syntax to use. This way I could have two separate sessions a bit like a KVM switch expect I'd have two monitors with one keyboard and mouse, and I would move my mouse over from one monitor to another to switch from one gnome session to another. so... how would I configure gdm to run on two X displays or servers? Thanks! Steve. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: multiple gdm
On Thu, Jan 15, 2015 at 10:08 AM, Stephen Adler ad...@stephenadler.com wrote: Thanks, just to be clear, I don't want one gnome session running on two X servers. I want to run two different instances of gnome, each with its own X server. The idea would be, if all is working, when I boot my system, I'll get two gdm login screens, one for each monitor. I could then have to log in twice, perhaps under different user names. It may sound like a bad hack, but I'm just wondering if somehow I could configure gdm to work of some specified display, like :0.0 or :0.1 or something like that. :0.0 and :0.1 refer to different screens (GPUs / root windows) under one X server, which is not supported. What I understand you want is :0 and :1, ie, two completely separate X servers. The easiest way to obtain that is to tag the different GPUs and input devices in different seats in udev rules - then GDM will automatically start an X server on each seat and you'll be able to login. Note that you must have two sets of input devices and two separate GPUs, because each server will take full control of one. The details for how to configure multiseat are at http://www.freedesktop.org/wiki/Software/systemd/multiseat/ Giovanni On Thu, 2015-01-15 at 09:45 -0800, Jasper St. Pierre wrote: GNOME does not support multiple X11 screens. My understanding is that recent versions of nvidia proprietary added XRandR as a feature, which is what we require for multi monitor support. On Jan 15, 2015 6:31 AM, Stephen Adler ad...@stephenadler.com wrote: Guys, I'm not sure if this is the right mailing list to ask this question so forgive if I miss-posted... I have a system with two video cards, quadro K2200 and a K620 and the nvidia propriatary driver will not configure a single desktop (X server) using both cards. It will configure two separate X servers or X displays, one for each card. So I thought maybe I could run two versions of gdm, one for each X server or X display (I'm not sure the terminology here.) :0.0 and :0.1 would be the -display syntax to use. This way I could have two separate sessions a bit like a KVM switch expect I'd have two monitors with one keyboard and mouse, and I would move my mouse over from one monitor to another to switch from one gnome session to another. so... how would I configure gdm to run on two X displays or servers? Thanks! Steve. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Bugzilla upgrade to release 4.4.6 - Testing needed
Hi there! I'm so glad to announce we made a tremendous jump ahead of having our Bugzilla istance upgraded to the latest stable release being 4.4.6. Thanks to the hard job of Krzesimir Nowak who spent the last few months migrating our customizations to the new codebase and to Olav Vitters who started the process a while back we are ready to announce the availability of a test istance based on Bugzilla 4.4.6 with all the customizations we have in place at bugzilla.gnome.org. Although have tested and are not aware of any blockers are still around to justify delaying the upgrade even longer we thought it was the case to give everyone a week for testing all the new features and GNOME customizations, specifically we would love receiving intensive testing on the following features: 1. Git-bz 2. Patch statuses extension (i.e [1]) 3. Splinter --- Warnings: --- Playing with patch statuses or attachments themselves will result in an ERR_CERT_COMMON_NAME_INVALID error which you can safely mark as safe and keep browsing the page you were looking for. The error will go away when we'll switch the SSL certificates to the ones we have in production. (the error is currently there as our proxies do have a wildcard certificate for the gnome.org domain which will only cover third-level subdomains and result in an error when used on fourth-level subdomains like in this case (bug%bugid.bugzilla-test-attachments.gnome.org)) If you'll be looking at [2] you'll see no weekly bug summary has been published, collectstats has run et all but the dump we used is around one month old so no, no stats are expected to be there on purpose. The weekly-bug-summary however supports the use of the days URL parameter. [3] --- Where is the test istance located? --- The test istance is located at https://bugzilla-test.gnome.org. The database is hosted on the same machine with all the limitations this may have, please don't overload the machine with huge queries. --- How do I report a bug I found? --- Please report all bugs at [4] making sure a [4.4] prefix is appended before the summary text --- How long will you keep the testing istance up before upgrading the production database? --- The testing istance will be kept up from today 15th to the 22th of January, so exactly one week from today. After this period if no blocker bugs have been reported bugzilla.gnome.org will be undergoing a 36 to 48 hours maintenance and the production database will be upgraded. [1] https://bugzilla-test.gnome.org/attachment.cgi?id=201923action=edit [2] https://bugzilla-test.gnome.org/page.cgi?id=weekly-bug-summary.html [3] https://bugzilla-test.gnome.org/page.cgi?id=weekly-bug-summary.htmldays=60 [4] https://bugzilla.gnome.org/enter_bug.cgi?product=bugzilla.gnome.orgshort_desc=%5B4.4%5D%20 -- Cheers, Andrea Debian Developer, Fedora / EPEL packager, GNOME Infrastructure Team Coordinator, GNOME Foundation Board of Directors Secretary, GNOME Foundation Membership Elections Committee Chairman Homepage: http://www.gnome.org/~av ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Bugzilla upgrade to release 4.4.6 - Testing needed
And two more details I missed: --- How can I login? --- If you didn't change your password between today and the 2014-12-08, your login will succeed by using the same login information as bugzilla.gnome.org. --- Can I update bugs without annoying people with e-mail notifications? --- Yes, you can. Currently e-mail notifications are disabled from the test instance so no one is going to receive a single notification from your actions. The database in use will be trashed when the testing week will end and the move to production will take place. cheers, 2015-01-15 19:46 GMT+01:00 Andrea Veri a...@gnome.org: Hi there! I'm so glad to announce we made a tremendous jump ahead of having our Bugzilla istance upgraded to the latest stable release being 4.4.6. Thanks to the hard job of Krzesimir Nowak who spent the last few months migrating our customizations to the new codebase and to Olav Vitters who started the process a while back we are ready to announce the availability of a test istance based on Bugzilla 4.4.6 with all the customizations we have in place at bugzilla.gnome.org. Although have tested and are not aware of any blockers are still around to justify delaying the upgrade even longer we thought it was the case to give everyone a week for testing all the new features and GNOME customizations, specifically we would love receiving intensive testing on the following features: 1. Git-bz 2. Patch statuses extension (i.e [1]) 3. Splinter --- Warnings: --- Playing with patch statuses or attachments themselves will result in an ERR_CERT_COMMON_NAME_INVALID error which you can safely mark as safe and keep browsing the page you were looking for. The error will go away when we'll switch the SSL certificates to the ones we have in production. (the error is currently there as our proxies do have a wildcard certificate for the gnome.org domain which will only cover third-level subdomains and result in an error when used on fourth-level subdomains like in this case (bug%bugid.bugzilla-test-attachments.gnome.org)) If you'll be looking at [2] you'll see no weekly bug summary has been published, collectstats has run et all but the dump we used is around one month old so no, no stats are expected to be there on purpose. The weekly-bug-summary however supports the use of the days URL parameter. [3] --- Where is the test istance located? --- The test istance is located at https://bugzilla-test.gnome.org. The database is hosted on the same machine with all the limitations this may have, please don't overload the machine with huge queries. --- How do I report a bug I found? --- Please report all bugs at [4] making sure a [4.4] prefix is appended before the summary text --- How long will you keep the testing istance up before upgrading the production database? --- The testing istance will be kept up from today 15th to the 22th of January, so exactly one week from today. After this period if no blocker bugs have been reported bugzilla.gnome.org will be undergoing a 36 to 48 hours maintenance and the production database will be upgraded. [1] https://bugzilla-test.gnome.org/attachment.cgi?id=201923action=edit [2] https://bugzilla-test.gnome.org/page.cgi?id=weekly-bug-summary.html [3] https://bugzilla-test.gnome.org/page.cgi?id=weekly-bug-summary.htmldays=60 [4] https://bugzilla.gnome.org/enter_bug.cgi?product=bugzilla.gnome.orgshort_desc=%5B4.4%5D%20 -- Cheers, Andrea Debian Developer, Fedora / EPEL packager, GNOME Infrastructure Team Coordinator, GNOME Foundation Board of Directors Secretary, GNOME Foundation Membership Elections Committee Chairman Homepage: http://www.gnome.org/~av -- Cheers, Andrea Debian Developer, Fedora / EPEL packager, GNOME Infrastructure Team Coordinator, GNOME Foundation Board of Directors Secretary, GNOME Foundation Membership Elections Committee Chairman Homepage: http://www.gnome.org/~av ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: multiple gdm
Thanks guys for the info. Very useful to know these details. Cheers. Steve. On Thu, 2015-01-15 at 10:32 -0800, Giovanni Campagna wrote: On Thu, Jan 15, 2015 at 10:08 AM, Stephen Adler ad...@stephenadler.com wrote: Thanks, just to be clear, I don't want one gnome session running on two X servers. I want to run two different instances of gnome, each with its own X server. The idea would be, if all is working, when I boot my system, I'll get two gdm login screens, one for each monitor. I could then have to log in twice, perhaps under different user names. It may sound like a bad hack, but I'm just wondering if somehow I could configure gdm to work of some specified display, like :0.0 or :0.1 or something like that. :0.0 and :0.1 refer to different screens (GPUs / root windows) under one X server, which is not supported. What I understand you want is :0 and :1, ie, two completely separate X servers. The easiest way to obtain that is to tag the different GPUs and input devices in different seats in udev rules - then GDM will automatically start an X server on each seat and you'll be able to login. Note that you must have two sets of input devices and two separate GPUs, because each server will take full control of one. The details for how to configure multiseat are at http://www.freedesktop.org/wiki/Software/systemd/multiseat/ Giovanni On Thu, 2015-01-15 at 09:45 -0800, Jasper St. Pierre wrote: GNOME does not support multiple X11 screens. My understanding is that recent versions of nvidia proprietary added XRandR as a feature, which is what we require for multi monitor support. On Jan 15, 2015 6:31 AM, Stephen Adler ad...@stephenadler.com wrote: Guys, I'm not sure if this is the right mailing list to ask this question so forgive if I miss-posted... I have a system with two video cards, quadro K2200 and a K620 and the nvidia propriatary driver will not configure a single desktop (X server) using both cards. It will configure two separate X servers or X displays, one for each card. So I thought maybe I could run two versions of gdm, one for each X server or X display (I'm not sure the terminology here.) :0.0 and :0.1 would be the -display syntax to use. This way I could have two separate sessions a bit like a KVM switch expect I'd have two monitors with one keyboard and mouse, and I would move my mouse over from one monitor to another to switch from one gnome session to another. so... how would I configure gdm to run on two X displays or servers? Thanks! Steve. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
setting primary monitor bug
Guys, I'm not sure where to submit this bug, but here goes. I'm running gnome on fedora 21. I have 3 (yes, 3, just added another one) 4K dell up3214q monitors hooked up to my desktop. The 4K monitor has the dual tile architecture to drive the full 4K at 60Hz, meaning that each monitor is actually two sub monitors (tiles) with a resolution of 1980x2160 placed side by side to make up one full monitor. So I have in effect 6 sub monitors or tiles (2 per physical monitor). When I go to arrange the tiles using the display setting tool, I had a hard time setting the primary tile. In the setup that I have, the order of the tiles, going from left to right as I look at my three monitors is 2, 1, 4, 3, 6, 5. So I want the left side of my center monitor to be the primary one. The only way I could do this was to set monitor #1 (the right side of my left monitor) to be the primary display and then reset the primary display to tile #4. When I first logged in, the primary display was set to tile #2. I then set the primary display (by accident) to monitor #3 thinking the order was 1, 2, 3, 4, 5, 6 and ended up with the primary display being on the right side of my center monitor. So I went to set it to tile #4 and it refused to set it there. I could then set tile #2, but not #4. I then set the primary display to tile #1 and then #4 at which point that actually worked. I don't know if this makes any sense, but I thought perhaps it was due to the large number of tiles I'm working with that it messed up the ability to set the primary display on tile #4 when the current primary display is set to any other tile. Anyhow... that's the bug. Cheers. Steve. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Installing DBus interface files for services
On Thu, 2015-01-15 at 14:40 +0800, Cosimo Cecchi wrote:
On Tue, Jan 13, 2015 at 4:08 PM, Philip Withnall
phi...@tecnocode.co.uk wrote:
I can’t think of any reasons why not. Perhaps a GDBus automake
snippet
could be installed by GLib which:
1. Installs D-Bus XML interface files.
2. Includes rules for building documentation and C/H files
from them.
3. Validates the XML interface files for well-formedness.
I think that would be really helpful; note that my goal here would be
just to make things more convenient for developers and not to use it
as a way to guarantee API stability of a service through
auto-generated code.
In that sense, I see your points 1), 3) and the first half of 2) as
something typically used by the service, and the second half of 2) as
something a consumer would call.
Yes, making sure the snippet doesn’t confuse the two use cases is a good
point.
Another thing that to take into consideration is that some projects
currently encode the location of the DBus interface xml into their
pkgconfig file [1].
Is that something we should recommend? I believe if we had this
snippet, the macro could just do a lookup following the usual rules of
XDG_DATA_DIRS and we could avoid using pkgconfig, but perhaps I'm
missing something.
IMO, no, we shouldn’t recommend that. The ‘${datadir}/dbus-1/interfaces’
path should be well known, and the interface files should follow the
interface names, which are already hard-coded into the client code
anyway (since it calls them). So we can avoid running pkg-config here.
Philip
signature.asc
Description: This is a digitally signed message part
___
desktop-devel-list mailing list
desktop-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/desktop-devel-list
Re: Standardizing the latest dev code Version field value in GNOME Bugzilla?
On Mon, 2015-01-12 at 21:28 +0100, Andre Klapper wrote: 2) Shall we standardize this? (I volunteer to rename; git master seems to be the most popular option.) Thank you everybody who replied. Only +1 replies so I'll go ahead and standardize this weekend if I find time. andre -- Andre Klapper | ak...@gmx.net http://blogs.gnome.org/aklapper/ ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
multiple gdm
Guys, I'm not sure if this is the right mailing list to ask this question so forgive if I miss-posted... I have a system with two video cards, quadro K2200 and a K620 and the nvidia propriatary driver will not configure a single desktop (X server) using both cards. It will configure two separate X servers or X displays, one for each card. So I thought maybe I could run two versions of gdm, one for each X server or X display (I'm not sure the terminology here.) :0.0 and :0.1 would be the -display syntax to use. This way I could have two separate sessions a bit like a KVM switch expect I'd have two monitors with one keyboard and mouse, and I would move my mouse over from one monitor to another to switch from one gnome session to another. so... how would I configure gdm to run on two X displays or servers? Thanks! Steve. ___ desktop-devel-list mailing list desktop-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/desktop-devel-list
