Re: [RFC] Allow fd.o to join forces with X.Org
On Wed, Oct 17, 2018 at 02:37:25PM +0200, Daniel Vetter wrote:
> On Wed, Oct 17, 2018 at 2:05 PM Daniel Stone wrote:
> >
> > On Tue, 16 Oct 2018 at 08:17, Peter Hutterer
> > wrote:
> > > On Mon, Oct 15, 2018 at 10:49:24AM -0400, Harry Wentland wrote:
> > > > + \item Support free and open source projects through the
> > > > freedesktop.org
> > > > + infrastructure. For projects outside the scope of item (\ref{1})
> > > > support
> > > > + extends to project hosting only.
> > > > +
> > >
> > > Yes to the idea but given that the remaining 11 pages cover all the
> > > legalese
> > > for xorg I think we need to add at least a section of what "project
> > > hosting"
> > > means. Even if it's just a "includes but is not limited to blah". And
> > > some
> > > addition to 4.1 Powers is needed to spell out what the BoD can do in
> > > regards
> > > to fdo.
> >
> > Yeah, I think it makes sense. Some things we do:
> > - provide hosted network services for collaborative development,
> > testing, and discussion, of open-source projects
> > - administer, improve, and extend this suite of services as necessary
> > - assist open-source projects in their use of these services
> > - purchase, lease, or subscribe to, computing and networking
> > infrastructure allowing these services to be run
>
> I fully agree that we should document all this. I don't think the
> bylaws are the right place though, much better to put that into
> policies that the board approves and which can be adapted as needed.
> Imo bylaws should cover the high-level mission and procedural details,
> as our "constitution", with the really high acceptance criteria of
> 2/3rd of all members approving any changes. Some of the early
> discussions tried to spell out a lot of the fd.o policies in bylaw
> changes, but then we realized it's all there already. All the details
> are much better served in policies enacted by the board, like we do
> with everything else.
>
> As an example, let's look at XDC. Definitely one of the biggest things
> the foundation does, with handling finances, travel sponsoring grants,
> papers committee, and acquiring lots of sponsors. None of this is
> spelled out in the bylaws, it's all in policies that the board
> deliberates and approves. I think this same approach will also work
> well for fd.o.
>
> And if members are unhappy with what the board does, they can fix in
> the next election by throwing out the unwanted directors.
yeah, fair call. though IMO in that case we can just reduce to
\item Support free and open source projects through the freedesktop.org
infrastructure.
because my gripe is less with the fdo bit but more with defining what
"project hosting" means, given that we use that term to exclude fdo projects
from getting anything else. I think just dropping that bit is sufficient.
Cheers,
Peter
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
[QXL PATCH 1/2] Make output name numbering 0-based
The QXL driver names its outputs starting at 0 (e.g. Virtual-0, Virtual-1, etc). This code was presumably copy/pasted from a different driver, and is not necessary for the QXL driver. Other drivers simply use the kernel connector_type_id which starts at 1. For example, the modsetting driver changed from 0-based names to 1-based names for the same reason in xserver commit 139e36dd. This will help to make it easier to identify which xrandr outputs belong to which drm connector without requiring as many driver-specific special-cases. This change might effect custom xorg configurations that references a specific output name. But the same change was made in modesetting driver despite that possibility. Signed-off-by: Jonathon Jongsma --- src/qxl_drmmode.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff --git a/src/qxl_drmmode.c b/src/qxl_drmmode.c index a2f84b1..a814859 100644 --- a/src/qxl_drmmode.c +++ b/src/qxl_drmmode.c @@ -765,8 +765,7 @@ drmmode_output_init(ScrnInfoPtr pScrn, drmmode_ptr drmmode, int num) } } - /* need to do smart conversion here for compat with non-kms ATI driver */ - snprintf(name, 32, "%s-%d", output_names[koutput->connector_type], koutput->connector_type_id - 1); + snprintf(name, 32, "%s-%d", output_names[koutput->connector_type], koutput->connector_type_id); output = xf86OutputCreate (pScrn, &drmmode_output_funcs, name); -- 2.17.2 ___ xorg-devel@lists.x.org: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: https://lists.x.org/mailman/listinfo/xorg-devel
[QXL PATCH 2/2] Make output names match modsetting driver
The xrandr output name used by the QXL driver is based on the drm
connector type, but the names do not match the kernel names (see
/drivers/gpu/drm/drm_connector.c) or the modsetting driver names (see
hw/xfree86/drivers/modesetting/drmmode_display.c). Making these more
consistent will require less driver-specific special-case code if a user
wants to match an xrandr output to a drm connector.
Note that this patch should not actually change any behavior, since the
QXL driver only uses the 'Virtual' connector type, so this is done only
for consistency.
Signed-off-by: Jonathon Jongsma
---
src/qxl_drmmode.c | 18 ++
1 file changed, 10 insertions(+), 8 deletions(-)
diff --git a/src/qxl_drmmode.c b/src/qxl_drmmode.c
index a814859..0f95499 100644
--- a/src/qxl_drmmode.c
+++ b/src/qxl_drmmode.c
@@ -722,20 +722,22 @@ static int subpixel_conv_table[7] = { 0, SubPixelUnknown,
const char *output_names[] = { "None",
"VGA",
- "DVI",
- "DVI",
- "DVI",
+ "DVI-I",
+ "DVI-D",
+ "DVI-A",
"Composite",
- "S-video",
+ "SVIDEO",
"LVDS",
- "CTV",
+ "Component",
"DIN",
- "DisplayPort",
- "HDMI",
+ "DP",
"HDMI",
+ "HDMI-B",
"TV",
"eDP",
- "Virtual"
+ "Virtual",
+ "DSI",
+ "DPI",
};
static void
--
2.17.2
___
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
