Re: [Mesa-dev] Querying Vulkan driver Options

[Jean Hertel]

From: Lionel Landwerlin 
>> - In case the options are different (which is quite likely), how do we query 
>> the available options?
>>
>> For OpenGL we have glXGetScreenDriver/glXGetDriverConfig
>>
>> For EGL we have eglGetDisplayDriverName/eglGetDisplayDriverConfig [2]
>>
>> What about Vulkan? How can we query such options?
>
>I guess you'll have to add an extension to provide the same feature.

Do we have any documentation or high level steps on writing a Vulkan extension?
>From mesa side, providing a Merge Request with the necessary changes is enough?

Kind regards,
Jean Hertel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] Querying Vulkan driver Options

[Jean Hertel]

Dear Mesa developers,

I'm looking into further improving adriconf[1] as a tool to configure mesa 
driver options.
Vulkan mesa drivers can now read their configuration options from the .drirc 
configuration file.
With this in mind I have the following question to mesa developers:

- Are Vulkan drivers using the same options as their OpenGL drivers?
  eg: Does Intel ANV uses the same options as i965?

- In case the options are different (which is quite likely), how do we query 
the available options?
For OpenGL we have glXGetScreenDriver/glXGetDriverConfig
For EGL we have eglGetDisplayDriverName/eglGetDisplayDriverConfig [2]
What about Vulkan? How can we query such options?

Kind regards,
Jean Hertel

[1]: https://github.com/jlHertel/adriconf
[2]: 
https://www.khronos.org/registry/EGL/extensions/MESA/EGL_MESA_query_driver.txt
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] MESA_query_driver segfaults with GBM display

[Jean Hertel]

Hello Veluri,

How you doing?

I'm experimenting with different ways to load and query drivers and found a 
very useful extension to get EGL displays directly from a gbm device.
The extension itself you can see here: 
https://www.khronos.org/registry/EGL/extensions/MESA/EGL_MESA_platform_gbm.txt

I'm now experimenting into using this to query the driver name and 
configurations directly, so we can get rid of the different implementations for 
X11 and Wayland.
So far querying the driver name is always successfull, but for some reason when 
I query the driver options I receive a segmentation fault from EGL.

Here is an example code showing the issue: 
https://gist.github.com/jlHertel/6a594b2d2d37d039ac383c8551c1b7bd
The curious part here is that using a egl display from 
eglGetDisplay(EGL_DEFAULT_DISPLAY) works fine.

Do you have any idea why this is failing?

Kind regards,
Jean Hertel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Move adriconf to mesa repositories

[Jean Hertel]

On 8th May you Wrote:
>Hi Emil,
>
>>This is the tricky part - wish I could find my notes they have better
>>brain-dump.
>>It's OK to have the library as both front (config tool) and backend
>>(used by mesa) although:
>> - special care on splitting and annotating the API is needed
>> - handling this "extra" dependency would be fiddly for slower moving distros
>>
>I'm not sure I get the whole picture of what you are suggesting, so I put some 
>ideas on how I think such API would work [here][1].
>
>>> What about the current configuration files? Do you think there is a better 
>>> way to handle them?
>>> They are for in a xml format, which is far from optimal.
>>>
>>What seems to be the problem with XML? The files are meant to be
>>read/written to $app.
>>
>
>I dislike XML because it is too ugly. Something more natural and easy to 
>read/write would be more interesting.
>Like a YML format. Ideally I would like to use JSON, but then it becomes a lot 
>harder for people to write this by hand in case the GUI tools don't offer >the 
>options they want/need.
>Of course this is just my point of view, and not necessarily a real issue.
>
>Kind Regards,
>Jean Hertel
>
>[1]: https://github.com/jlHertel/libdriconfig/blob/master/USAGE.md

Hey Emil,
Did you get a chance to look in my proposed way of building this new API?

Some comments would be welcome.
Also,  CC'ing Rob, as I think he would also have interest in this.

Kind Regards,
Jean Hertel 
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Move adriconf to mesa repositories

[Jean Hertel]

Hi Emil,

>This is the tricky part - wish I could find my notes they have better
>brain-dump.
>It's OK to have the library as both front (config tool) and backend
>(used by mesa) although:
> - special care on splitting and annotating the API is needed
> - handling this "extra" dependency would be fiddly for slower moving distros
>
I'm not sure I get the whole picture of what you are suggesting, so I put some 
ideas on how I think such API would work [here][1]. 

>> What about the current configuration files? Do you think there is a better 
>> way to handle them?
>> They are for in a xml format, which is far from optimal.
>>
>What seems to be the problem with XML? The files are meant to be
>read/written to $app.
>

I dislike XML because it is too ugly. Something more natural and easy to 
read/write would be more interesting.
Like a YML format. Ideally I would like to use JSON, but then it becomes a lot 
harder for people to write this by hand in case the GUI tools don't offer the 
options they want/need. 
Of course this is just my point of view, and not necessarily a real issue.

Kind Regards,
Jean Hertel

[1]: https://github.com/jlHertel/libdriconfig/blob/master/USAGE.md
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Move adriconf to mesa repositories

[Jean Hertel]

>Could not find my original notes, but the idea is roughly as follows:
 >- introduce a separate (user only?) library - say libmesa-config.so
> - ^^ provides an API to query/set attributes, via numerical tokens
> - any localisation is built on top of ^^ as standalone files
>
>Reasoning:
>- library reused by anyone to make a pretty config tool in their
>toolkit and/or language
> - numerical tokens are trivial to handle and cheap - can be
>binned/deprecated easily
> - translation lives outside of the driver - the driver doesn't care
>about it, so don't bloat
> - translators do not need access to mesa - one less hurdle/obstacle
>
>
>Hope it makes sense, not sure if coffee has kicked in fully ;-)
>-Emil

Hey Emil,

I really liked this idea, specially since right now I have a lot of issues to 
query which option is exactly supported by each driver. Like in the scenarios 
when you have multiple drivers that support the same GPU, or when you have a 
difference between userspace and kernel space driver naming.

Can you give me more details on the idea?
If I got it right, this library would be independent and mesa will itself use 
it to query the options it wants/needs.

What about the current configuration files? Do you think there is a better way 
to handle them?
They are for in a xml format, which is far from optimal.

What about Vulkan?
As far as I known the current setup only handles OpenGL driver configurations.

Kind Regards,
Jean Hertel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Move adriconf to mesa repositories

[Jean Hertel]

Any other mesa developer interested in seeing this move forward?

Kind Regards,
Jean Hertel

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Move adriconf to mesa repositories

[Jean Hertel]

>That said, I don't mind if the project migrates under
>gitlab.fd.o/mesa/ - it would be beneficial to have it close-by.
>
>What I would strongly suggest is to add some documentation about patch
>submission, review process and releasing criteria/process.
>
I updated the docs on how to submit patches and how I'm doing releases.
https://github.com/jlHertel/adriconf/blob/master/CONTRIBUTING.md

Kind Regards,
Jean Hertel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Move adriconf to mesa repositories

[Jean Hertel]

Hi Trevor,

From: Trevor Woerner  
>On Mon 2019-04-01 @ 08:55:56 PM, Jean Hertel wrote:
>> - What about GSOC? On the X.Org [page][2] there is still a driconf
>> replacement idea. If we move, can we replace this with some adriconf
>> improvement ideas?
>>
>> [2]: https://www.x.org/wiki/SummerOfCodeIdeas/
>
>Are you interested in doing this as a GSOC project? Or merely pointing out
>that there is a GSOC suggestion for a project that is similar to what you're
>proposing?
Actually adriconf is exactly what this GSOC project is proposing:
a DriConf replacement with some improvements.

>Are you able to edit the wiki as Rob suggests? If not, I should be able to
>edit it.
I don't have any write permissions to the wiki. Not even a freedesktop account.
But I would prefer to have the project properly migrated under mesa
umbrella before editing any content of the wiki.

If you are more interested in the project, feel free to take a look [here][1].

Kind Regards,
Jean Hertel

[1]: https://github.com/jlHertel/adriconf/
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Move adriconf to mesa repositories

[Jean Hertel]

From: Emil Velikov 
Sent: 4th april, 2019 13:08
>Yes I have interest in a configuration tool, although my vision varies
>a lot from what adriconf and its predecessor.

I'm super interested and open to hear yours, and other mesa devs, ideas 
on how a good configuration utility should look and behave.
Feel free to reach over with ideas/suggestions/visions.
Anything you think could make the current situation better.

>That said, I don't mind if the project migrates under
>gitlab.fd.o/mesa/ - it would be beneficial to have it close-by.
>
>What I would strongly suggest is to add some documentation about patch
>submission, review process and releasing criteria/process.

I will try to come up with something this weekend regarding
patch submission, reviews and release criteria.
As soon as I have some documentation I will come back to you.

Thanks for the feedback on this.

Kind Regards,
Jean Hertel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] Move adriconf to mesa repositories

[Jean Hertel]

Hey Emil,

You also showed interest in this project in the past.
Any thoughts about moving it to mesa gitlab?

Kind Regards,
Jean Hertel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] Move adriconf to mesa repositories

[Jean Hertel]

Hi Rob,

As we have spoken already in the past, I have the intention to move adriconf 
under the mesa project umbrella, as an official tool for configuring DRI 
options.
I would like to ask your advice, as well as other mesa developers, on how to 
properly do this. (If people is willing to accept it)
So far the questions I have are:

- What is the proccess to become an official mesa tool?
- Do I need any approval? Like from other mesa developers or X.Org Foundation?
- In this proccess, can we rename the adriconf to use a proper mesa namespace? 
Right now it is named as br.com.jeanhertel.adriconf which is quite weird, as 
the intention is not to be a comercial tool. See [Flathub][1].
- Also, what about gitlab? If we move, can we use it? I already know the tool 
and would really appreciate using it.
- Is there anyone else willing to have commit rights on it? I known the project 
is public, but I feel it would be nice to have someone else also with 
commit/admin rights in case I'm hit by a bus :)
- What about GSOC? On the X.Org [page][2] there is still a driconf replacement 
idea. If we move, can we replace this with some adriconf improvement ideas?

Kind Regards,
Jean Hertel

[1]: https://flathub.org/apps/details/br.com.jeanhertel.adriconf
[2]: https://www.x.org/wiki/SummerOfCodeIdeas/
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] adriconf - Packaging

[Jean Hertel]

From: Veluri Mithun 
>Hi all,

About sandbox 
permissions<http://docs.flatpak.org/en/latest/sandbox-permissions-reference.html?highlight=talk-name#sandbox-permissions>
What should we use for these --talk-name=, --system-talk-name, --filesystem= 
finish options?
Do we need to use these???
  "--talk-name=org.freedesktop.Dbus",
  "--system-talk-name=org.freedesktop.Dbus",
  "--filesystem=host" (since we will rw: user-defined, system-wide, 
mesa-source code )

>
>I've built the flatpak app for adriconf successfully and shortly I'll publish 
>it in flathub. But, before that I need to clarify >few doubts
>
>app-Id<https://nam03.safelinks.protection.outlook.com/?url=http%3A%2F%2Fdocs.flatpak.org%2Fen%2Flatest%2Fconventions.html%23application-ids=02%7C01%7C%7C7a155736c7544e9cd58008d611d9c495%7C84df9e7fe9f640afb435%7C1%7C0%7C636716024329438331=rU%2FWeWMAK4MnB%2FGcaPoLwIpMGWuWQDMGIflNJWaC5JA%3D=0>:
> org.x.adriconf
>
>@Rob Clark<mailto:robdcl...@gmail.com>  and @Jean 
>Hertel<mailto:jean.her...@hotmail.com> Please confirm about it.


>That error is related to the app-Id we are using more detatils can be seen 
>here(https://github.com/flathub/flathub/pull/605#issuecomment-419066807) and 
>Nick Richards(memeber of flathub) is suggesting me to use another domain.
>
>please have a look 
>here(https://github.com/flathub/flathub/pull/605#issuecomment-419066807)  and 
>let me know what app-Id should I use?
>
>Thanks,
>Veluri.


Hi Veluri,


I would be really happy if we could move the entire code to the mesa namespace 
on fdo, but I think this can take some time, and to be honest I was hopping to 
mature the code a little bit more before moving it there.


As we also don't know why the app is getting this crazy namespace, I think the 
most sane thing to do now is just use the name br.com.jeanhertel.adriconf .


Can you kindly update it?

Kind Regards,
Jean Hertel

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] New EGL extension in mesa and 'adriconf' packaging - EVoC'18

[Jean Hertel]

Emil Velikov  wrote:

>Hi everyone,
>
>As Veluri has noticed, I made a few comments earlier to his proposal/plans.
>Having a comprehensive configuration tool is a great task, although
>there is an underlying issue as pointed out [A].
>
>Or looking for a proper solution for [A]. Since that hack is for GLX
>and we will need something alike it EGL. Ideally, a lot less hacky.
>Sadly, resolving that is outside of my scope for the moment, but I am
>happy to answer questions ;-)
>
>[A]  
>https://github.com/jlHertel/adriconf/commit/9c1c98633faff7b6b15be443da5cb9d8e90c50dd#diff->e9ffd8eaf9c59af94bc9cef7564301e5R14

Hi Emil,

I think the biggest question here is: are we able to use only EGL and 
completely drop the Xlib calls even on a X.Org only application? 

If yes, then I think the best approach would be to make a EGL extension based 
on the two functions, and simply ignore the existing ones, so that 
backwars-compatibility stays the same.

Apart from xdriinfo, driconf and adriconf, I don't think any other application 
uses those two functions, but in any case I think is better to don't break 
things.

Kind Regards,
Jean Hertel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 0/1] Add pt_BR translations

[Jean Hertel]

Hi,

This is my first patch to the mesa-dev list, so feel free to point any mistake 
you find.

Jean Hertel (1):
  Add pt_BR translation to driver options

 src/util/xmlpool/Makefile.am |   2 +-
 src/util/xmlpool/meson.build |   2 +-
 src/util/xmlpool/pt_BR.po| 444 +++
 3 files changed, 446 insertions(+), 2 deletions(-)
 create mode 100644 src/util/xmlpool/pt_BR.po

-- 
2.18.0

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [PATCH 1/1] Add pt_BR translation to driver options

[Jean Hertel]

Signed-off-by: Jean Hertel 
---
 src/util/xmlpool/Makefile.am |   2 +-
 src/util/xmlpool/meson.build |   2 +-
 src/util/xmlpool/pt_BR.po| 444 +++
 3 files changed, 446 insertions(+), 2 deletions(-)
 create mode 100644 src/util/xmlpool/pt_BR.po

diff --git a/src/util/xmlpool/Makefile.am b/src/util/xmlpool/Makefile.am
index 0ef7a5462a..2413312f59 100644
--- a/src/util/xmlpool/Makefile.am
+++ b/src/util/xmlpool/Makefile.am
@@ -41,7 +41,7 @@
 # - info gettext
 
 # The set of supported languages. Add languages as needed.
-POS=ca.po de.po es.po nl.po fr.po sv.po
+POS=ca.po de.po es.po nl.po fr.po sv.po pt_BR.po
 
 #
 # Don't change anything below, unless you know what you're doing.
diff --git a/src/util/xmlpool/meson.build b/src/util/xmlpool/meson.build
index 97693fac8c..204feea84f 100644
--- a/src/util/xmlpool/meson.build
+++ b/src/util/xmlpool/meson.build
@@ -24,5 +24,5 @@ xmlpool_options_h = custom_target(
   output : 'options.h',
   command : [prog_python2, '@INPUT@', meson.current_source_dir()],
   capture : true,
-  depend_files : files('ca.po', 'es.po', 'de.po', 'nl.po', 'sv.po', 'fr.po'),
+  depend_files : files('ca.po', 'es.po', 'de.po', 'nl.po', 'sv.po', 'fr.po', 
'pt_BR.po'),
 )
diff --git a/src/util/xmlpool/pt_BR.po b/src/util/xmlpool/pt_BR.po
new file mode 100644
index 00..44bcf6a988
--- /dev/null
+++ b/src/util/xmlpool/pt_BR.po
@@ -0,0 +1,444 @@
+# Portuguese translations for DRI driver options.
+# Copyright (C) 2018 Jean Hertel
+# This file is distributed under the same license as the Mesa package.
+# Jean Hertel , 2018.
+#
+msgid ""
+msgstr ""
+"Project-Id-Version: PACKAGE VERSION\n"
+"Report-Msgid-Bugs-To: \n"
+"POT-Creation-Date: 2018-08-04 10:42-0300\n"
+"PO-Revision-Date: 2018-08-04 10:42-0300\n"
+"Last-Translator: Jean Hertel \n"
+"Language-Team: Brazilian Portuguese\n"
+"Language: pt_BR\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+"Plural-Forms: nplurals=2; plural=(n > 1);\n"
+
+#: t_options.h:56
+msgid "Debugging"
+msgstr "Depuração"
+
+#: t_options.h:60
+msgid "Disable 3D acceleration"
+msgstr "Desabilitar aceleração 3D"
+
+#: t_options.h:65
+msgid "Show performance boxes"
+msgstr "Exibir caixas de desempenho"
+
+#: t_options.h:70
+msgid "Enable flushing batchbuffer after each draw call"
+msgstr "Habilitar o flush do batchbuffer após cada chamada de desenho"
+
+#: t_options.h:75
+msgid "Enable flushing GPU caches with each draw call"
+msgstr "Habilitar o flush dos caches da GPU após cada chamada de desenho"
+
+#: t_options.h:80
+msgid "Disable throttling on first batch after flush"
+msgstr "Desabilitar throttling no primeiro lote após o flush"
+
+#: t_options.h:85
+msgid "Force GLSL extension default behavior to 'warn'"
+msgstr "Forçar o comportamento padrão da extensão GSLS para 'warn'"
+
+#: t_options.h:90
+msgid "Disable dual source blending"
+msgstr "Desabilitar blending de fonte dupla"
+
+#: t_options.h:95
+msgid "Identify dual color blending sources by location rather than index"
+msgstr "Identificar blending de fonte dupla por localização ao invés de índice"
+
+#: t_options.h:100
+msgid "Disable backslash-based line continuations in GLSL source"
+msgstr ""
+"Desabilitar continuações de linhas baseadas em barra invertida no código GLSL"
+
+#: t_options.h:105
+msgid "Disable GL_ARB_shader_bit_encoding"
+msgstr "Desabilitar GL_ARB_shader_bit_encoding"
+
+#: t_options.h:110
+msgid ""
+"Force a default GLSL version for shaders that lack an explicit #version line"
+msgstr ""
+"Forçar uma versão GLSL padrão para shaders que não possuem uma linha "
+"#version explícita"
+
+#: t_options.h:115
+msgid "Allow GLSL #extension directives in the middle of shaders"
+msgstr "Permitir diretivas GLSL #extension no meio dos shaders"
+
+#: t_options.h:120
+msgid "Allow builtins as part of constant expressions"
+msgstr "Permitir builtins como parte de expressões constantes"
+
+#: t_options.h:125
+msgid "Allow some relaxation of GLSL ES shader restrictions"
+msgstr "Permitir algum relaxamento das restrições de shader GLSL ES"
+
+#: t_options.h:130
+msgid "Allow GLSL built-in variables to be redeclared verbatim"
+msgstr "Permitir que variáveis GLSL bult-in sejam redeclaradas textualmente"
+
+#: t_options.h:135
+msgid "Allow a higher compat profile (version 3.1+) for apps that request it"
+msgstr ""
+"Permitir um perfil de compatibilidade maior (versão 3.1+) para apps que "
+"req

Re: [Mesa-dev] [RFC] - Rewrite mesa website in Sphinx

[Jean Hertel]

Hi Laura,


Aurelio Silves pointed me out that there is the possibility of using pandoc for 
the conversion of mesa html sources to rst.

You can take a look here: https://pandoc.org/index.html

Depending on your distribution, probably there is a package for this.


Also, if there is anything else I can do, send me an email and I will do the 
best I can to help.


Kind Regards,

Jean Hertel


De: Jean Hertel <jean.her...@hotmail.com>
Enviado: segunda-feira, 2 de abril de 2018 21:19
Para: Laura Ekstrand
Cc: Emil Velikov; Vedran Miletić; mesa-dev@lists.freedesktop.org; Jason Ekstrand
Assunto: Re: [Mesa-dev] [RFC] - Rewrite mesa website in Sphinx

Hi Laura,

I haven't used any script.
I made all the HTML to rst translations by hand, file by file.

Kind Regards,
Jean Hertel

Em 2 de abril de 2018 19:09:34 BRT, Laura Ekstrand <la...@jlekstrand.net> 
escreveu:
Hi Jean,

I'm going to play around with your patches to get them into a format that Mesa 
devs can review.  This will blow the history away.

The problem is that your workflow in 1 & 2 ruins the Git history for reviewers. 
 It makes the patch series hard to read.

Could you provide us with your script for translating HTML to rst?  Go ahead 
and commit it to your repo as a patch.

Thanks.

Laura

On Sun, Apr 1, 2018 at 6:12 AM, Jean Hertel 
<jean.her...@hotmail.com<mailto:jean.her...@hotmail.com>> wrote:

Hi Laura,


The commits have the idea of being atomic, so it makes sense to have a lot of 
them.

Some of them are just fixes, and can be squashed.


Please keep in mind that no CSS file is supposed to live there, as we are using 
an existing template from readTheDocs.

The commits are doing mainly two things:

1 - Create a new file and translate the old HTML content into a rst format.

2 - Delete the old file


Kind Regards,

Jean Hertel


De: Laura Ekstrand <la...@jlekstrand.net<mailto:la...@jlekstrand.net>>
Enviado: sábado, 31 de março de 2018 22:06
Para: Jean Hertel
Cc: Emil Velikov; Vedran Miletić; 
mesa-dev@lists.freedesktop.org<mailto:mesa-dev@lists.freedesktop.org>; Jason 
Ekstrand
Assunto: Re: [Mesa-dev] [RFC] - Rewrite mesa website in Sphinx

Jean,

I've taken at look at your sphinx-docs branch 
(https://github.com/jlHertel/mesa).

Oh my you have a lot of commits there!  It would be simpler for me to review if 
you could squash some of them together.

I am thinking a series on the order of 30 patches to start - just the pretty 
CSS stuff in Sphinx.

Once we get the page to look nicer, then we can start editing the content for 
readability!!!

Thanks.

Laura

On Sat, Mar 31, 2018 at 5:57 PM, Laura Ekstrand 
<la...@jlekstrand.net<mailto:la...@jlekstrand.net>> wrote:
Hello Jean,

Has anyone reviewed your patch series yet?   I would like to get these website 
updates moving.

Thanks.

Laura

On Tue, Jun 6, 2017 at 10:43 AM, Jean Hertel 
<jean.her...@hotmail.com<mailto:jean.her...@hotmail.com>> wrote:
Hello Emil,

I've updated the website with the new release notes template.

Please take a look at: http://mesa2.jeanhertel.com.br/relnotes.html


What about rebasing my current work on top of mesa-master?
(Remembering that github comments referencing directly the commit will be loss)


The repository: https://github.com/jlHertel/mesa
Demo site: http://mesa2.jeanhertel.com.br/

Best regards,
Jean Hertel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org<mailto:mesa-dev@lists.freedesktop.org>
https://lists.freedesktop.org/mailman/listinfo/mesa-dev




--
Enviado de meu dispositivo Android com K-9 mail. Desculpe-me pela brevidade.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] - Rewrite mesa website in Sphinx

[Jean Hertel]

Hi Laura,

I haven't used any script.
I made all the HTML to rst translations by hand, file by file.

Kind Regards,
Jean Hertel

Em 2 de abril de 2018 19:09:34 BRT, Laura Ekstrand <la...@jlekstrand.net> 
escreveu:
Hi Jean,

I'm going to play around with your patches to get them into a format that Mesa 
devs can review.  This will blow the history away.

The problem is that your workflow in 1 & 2 ruins the Git history for reviewers. 
 It makes the patch series hard to read.

Could you provide us with your script for translating HTML to rst?  Go ahead 
and commit it to your repo as a patch.

Thanks.

Laura

On Sun, Apr 1, 2018 at 6:12 AM, Jean Hertel 
<jean.her...@hotmail.com<mailto:jean.her...@hotmail.com>> wrote:

Hi Laura,


The commits have the idea of being atomic, so it makes sense to have a lot of 
them.

Some of them are just fixes, and can be squashed.


Please keep in mind that no CSS file is supposed to live there, as we are using 
an existing template from readTheDocs.

The commits are doing mainly two things:

1 - Create a new file and translate the old HTML content into a rst format.

2 - Delete the old file


Kind Regards,

Jean Hertel


De: Laura Ekstrand <la...@jlekstrand.net<mailto:la...@jlekstrand.net>>
Enviado: sábado, 31 de março de 2018 22:06
Para: Jean Hertel
Cc: Emil Velikov; Vedran Miletić; 
mesa-dev@lists.freedesktop.org<mailto:mesa-dev@lists.freedesktop.org>; Jason 
Ekstrand
Assunto: Re: [Mesa-dev] [RFC] - Rewrite mesa website in Sphinx

Jean,

I've taken at look at your sphinx-docs branch 
(https://github.com/jlHertel/mesa).

Oh my you have a lot of commits there!  It would be simpler for me to review if 
you could squash some of them together.

I am thinking a series on the order of 30 patches to start - just the pretty 
CSS stuff in Sphinx.

Once we get the page to look nicer, then we can start editing the content for 
readability!!!

Thanks.

Laura

On Sat, Mar 31, 2018 at 5:57 PM, Laura Ekstrand 
<la...@jlekstrand.net<mailto:la...@jlekstrand.net>> wrote:
Hello Jean,

Has anyone reviewed your patch series yet?   I would like to get these website 
updates moving.

Thanks.

Laura

On Tue, Jun 6, 2017 at 10:43 AM, Jean Hertel 
<jean.her...@hotmail.com<mailto:jean.her...@hotmail.com>> wrote:
Hello Emil,

I've updated the website with the new release notes template.

Please take a look at: http://mesa2.jeanhertel.com.br/relnotes.html


What about rebasing my current work on top of mesa-master?
(Remembering that github comments referencing directly the commit will be loss)


The repository: https://github.com/jlHertel/mesa
Demo site: http://mesa2.jeanhertel.com.br/

Best regards,
Jean Hertel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org<mailto:mesa-dev@lists.freedesktop.org>
https://lists.freedesktop.org/mailman/listinfo/mesa-dev




--
Enviado de meu dispositivo Android com K-9 mail. Desculpe-me pela brevidade.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] - Rewrite mesa website in Sphinx

[Jean Hertel]

Hi Laura,


The commits have the idea of being atomic, so it makes sense to have a lot of 
them.

Some of them are just fixes, and can be squashed.


Please keep in mind that no CSS file is supposed to live there, as we are using 
an existing template from readTheDocs.

The commits are doing mainly two things:

1 - Create a new file and translate the old HTML content into a rst format.

2 - Delete the old file


Kind Regards,

Jean Hertel


De: Laura Ekstrand <la...@jlekstrand.net>
Enviado: sábado, 31 de março de 2018 22:06
Para: Jean Hertel
Cc: Emil Velikov; Vedran Miletić; mesa-dev@lists.freedesktop.org; Jason Ekstrand
Assunto: Re: [Mesa-dev] [RFC] - Rewrite mesa website in Sphinx

Jean,

I've taken at look at your sphinx-docs branch 
(https://github.com/jlHertel/mesa).

Oh my you have a lot of commits there!  It would be simpler for me to review if 
you could squash some of them together.

I am thinking a series on the order of 30 patches to start - just the pretty 
CSS stuff in Sphinx.

Once we get the page to look nicer, then we can start editing the content for 
readability!!!

Thanks.

Laura

On Sat, Mar 31, 2018 at 5:57 PM, Laura Ekstrand 
<la...@jlekstrand.net<mailto:la...@jlekstrand.net>> wrote:
Hello Jean,

Has anyone reviewed your patch series yet?   I would like to get these website 
updates moving.

Thanks.

Laura

On Tue, Jun 6, 2017 at 10:43 AM, Jean Hertel 
<jean.her...@hotmail.com<mailto:jean.her...@hotmail.com>> wrote:
Hello Emil,

I've updated the website with the new release notes template.

Please take a look at: http://mesa2.jeanhertel.com.br/relnotes.html


What about rebasing my current work on top of mesa-master?
(Remembering that github comments referencing directly the commit will be loss)


The repository: https://github.com/jlHertel/mesa
Demo site: http://mesa2.jeanhertel.com.br/

Best regards,
Jean Hertel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org<mailto:mesa-dev@lists.freedesktop.org>
https://lists.freedesktop.org/mailman/listinfo/mesa-dev


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] - Rewrite mesa website in Sphinx

[Jean Hertel]

Hi Laura,


Unfortunately this repository was not reviewed.

It is already one year old, so its pretty outdated now.


If you are able to get enough people to review it, I can of course update it to 
mesa-git.


Kind Regards,

Jean Hertel


De: Laura Ekstrand <la...@jlekstrand.net>
Enviado: sábado, 31 de março de 2018 21:57
Para: Jean Hertel
Cc: Emil Velikov; Vedran Miletić; mesa-dev@lists.freedesktop.org; Jason Ekstrand
Assunto: Re: [Mesa-dev] [RFC] - Rewrite mesa website in Sphinx

Hello Jean,

Has anyone reviewed your patch series yet?   I would like to get these website 
updates moving.

Thanks.

Laura

On Tue, Jun 6, 2017 at 10:43 AM, Jean Hertel 
<jean.her...@hotmail.com<mailto:jean.her...@hotmail.com>> wrote:
Hello Emil,

I've updated the website with the new release notes template.

Please take a look at: http://mesa2.jeanhertel.com.br/relnotes.html


What about rebasing my current work on top of mesa-master?
(Remembering that github comments referencing directly the commit will be loss)


The repository: https://github.com/jlHertel/mesa
Demo site: http://mesa2.jeanhertel.com.br/

Best regards,
Jean Hertel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org<mailto:mesa-dev@lists.freedesktop.org>
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [GSOC] DriConf Replacement

[Jean Hertel]

Hi Axel,
  

>Hi all,
>
>Don't hesitate to recycle parts of my old try at DriConf Replacement:
>
>https://github.com/axeldavy/driCenter
>
>It had automatic detection of prime system and of the device_id.
>It detected also on which card apps run, and running apps.

Thanks for pointing this out.
Right now I'm enumerating the devices using libDrm, but it's good to know that 
there are more ways to achieve the same results.

Regards,
Jean

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] DRI Configurator replacement announcement

[Jean Hertel]

De: Gert Wollny <gw.foss...@gmail.com>
Enviado: terça-feira, 16 de janeiro de 2018 05:33
Para: Jean Hertel; mesa-dev@lists.freedesktop.org
Assunto: Re: [Mesa-dev] DRI Configurator replacement announcement
  
>> - Applications with empty options (all options are the same as
>> system-wide config or driver default) will be removed automatically
>I don't think that is such a good idea, what happens if someone wants
>to try out options to compare to the defaults? The application
>shouldn't get removed automatically when the user sets all to default.

I changed this with ed24a672a68529d6aa8e8d886009605411ae5379.
Now only system-wide applications that have all empty options get removed 
(after all, they will still be there on the next run, and it doesn't make sense 
to write empty tags on the user's .drirc file)


Also, if anyone else reading this has a PRIME setup (two GPUs from same vendor, 
usually found in notebooks), I would be very happy to take a look on it so the 
software can correctly support it. 
If this is your case, please open a github issue and post the contents of the 
following commands for me:
xdriinfo
for each screen/driver also run:
xdriinfo options SCREENNUMBER

Please provide also your local configurations located under $HOME/.drirc

The contributions are really appreciated.

Kind Regards,
Jean Hertel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [GSOC] DriConf Replacement

[Jean Hertel]

Hello Michel,
Hello Nicolai,

I have spent some more time reading the Mesa source code and trying to figure 
out how the prime configuration works.
If i understood correctly the driconf XML format should have an option inside 
each application indicating if PRIME should be used. This option is named 
"device_id" and defines the device which this application should run.

So when Mesa loads the configuration, if the application has the "device_id" it 
will run under this driver. Am I correct?
If this is the case, then to correctly support PRIME the expected behavior of 
the configuration GUI should be:
1 - Find out if this is a PRIME setup
2 - If its PRIME, give the user an option to select on which device this 
application should run.

Some more questions that I still have to understand:
- How do we detect at user-land that we are under a PRIME setup?

- I suppose there is some way to query the device_id directly from Mesa (maybe 
using Xlib). Any idea which API can be called for this?

- Having the device_id, how can I get additional data for this device (for 
example the vendor name and the full hardware description). I assume there is 
already an API that makes this possible, as the actual driconf is capable of 
identifying the hardware correctly.

Sorry If I'm making too much questions, but I'm really interested in understand 
how this work.

Kind Regards,
Jean Hertel


De: Jean Hertel <jean.her...@hotmail.com>
Enviado: domingo, 7 de janeiro de 2018 20:10
Para: Michel Dänzer; Nicolai Hähnle
Cc: mesa-dev@lists.freedesktop.org
Assunto: Re: [Mesa-dev] [GSOC] DriConf Replacement
  

Hello Michael,

Finally I found some free time to spent on this.
Can you please give me a small example on how I can get the device_ids ?

Currently to retrieve the available driver options I'm doing something like 
this:

1 - Count the number of screens using "ScreenCount" function from Xlib.
2 - For each screen retrieve the driver name with "glXGetScreenDriver".
3 - For each driver retrieve the available options with "glXGetDriverConfig".

Please note that my knowledge about openGL, x11 and mesa is almost zero, so if 
you have any documentation that I can read it would be nice too.

Kind Regards,
Jean Hertel

-
On 10/04/17 06:02 AM, Michel Dänzer wrote:
  
>On 05/04/17 05:26 PM, Nicolai Hähnle wrote:
>> On 04.04.2017 01:52, Jean Hertel wrote:
>> 
>> 2c) Consider adding an option to configure PRIME to driconf.
>> 
>> [2b and 2c will also require changes in Mesa; also, you may want to get
>> rid of the implicit dependency on xdriinfo]
>
>FWIW, Mesa already supports 2c) with DRI3, via the device_id option.
>
>

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] DRI Configurator replacement announcement

[Jean Hertel]

Hello,

I have written a simply application like DRI Conf tool.
It is written using GTKmm and C++.

Main Features (apart from what is already available in driconf):
- Automatic removal of invalid options (Options that the driver doesn't support 
at all)
- Options that have the same value as the system wide options or driver default 
will be ignored
- Applications with empty options (all options are the same as system-wide 
config or driver default) will be removed automatically

Current TODOs:
- Properly support a system without X (wayland systems?) Currently the glX 
functions mandate a Xlib display object. There must be another way to get the 
driver options
- Properly deal with PRIME setups (how do we get more information from the 
driver? hardware ids?)
- Some code cleanups. I'm not very experienced with C++ yet (Maybe split the 
GUI class, as it is very big and not very readable)
- Tests? Implementing testing for the software would be very nice
- Remove Boost dependency? (Currently boost.locale is used to get the ISO-639 
language id, to properly parse Mesa3d translations)

My main motivation for this project is to learn C++/GTKmm and a little bit more 
about Mesa itself, so if you read the code, be carefull that hidden bugs can be 
there.

Any feedback or hint on how to solve the TODOs list is very welcome.
Also, as this is a project for learning, feel free to point anything wrong with 
the code. I will be very happy to fix it and learn more.

Source is under github: https://github.com/jlHertel/adriconf

Kind Regards,
Jean Hertel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [GSOC] DriConf Replacement

[Jean Hertel]

Hello Michael,

Finally I found some free time to spent on this.
Can you please give me a small example on how I can get the device_ids ?

Currently to retrieve the available driver options I'm doing something like 
this:

1 - Count the number of screens using "ScreenCount" function from Xlib.
2 - For each screen retrieve the driver name with "glXGetScreenDriver".
3 - For each driver retrieve the available options with "glXGetDriverConfig".

Please note that my knowledge about openGL, x11 and mesa is almost zero, so if 
you have any documentation that I can read it would be nice too.

Kind Regards,
Jean Hertel

-
On 10/04/17 06:02 AM, Michel Dänzer wrote:
  
>On 05/04/17 05:26 PM, Nicolai Hähnle wrote:
>> On 04.04.2017 01:52, Jean Hertel wrote:
>> 
>> 2c) Consider adding an option to configure PRIME to driconf.
>> 
>> [2b and 2c will also require changes in Mesa; also, you may want to get
>> rid of the implicit dependency on xdriinfo]
>
>FWIW, Mesa already supports 2c) with DRI3, via the device_id option.
>
>
>-- 
>Earthling Michel Dänzer   |    http://www.amd.com
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] - Rewrite mesa website in Sphinx

[Jean Hertel]

Hello Emil,

I've updated the website with the new release notes template.

Please take a look at: http://mesa2.jeanhertel.com.br/relnotes.html


What about rebasing my current work on top of mesa-master?
(Remembering that github comments referencing directly the commit will be loss)


The repository: https://github.com/jlHertel/mesa
Demo site: http://mesa2.jeanhertel.com.br/

Best regards,
Jean Hertel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] - Rewrite mesa website in Sphinx

[Jean Hertel]

From: Emil Velikov <emil.l.veli...@gmail.com>
Sended: 24 May 2017 04:53   
>I was looking at it yesterday, and should have most of it done some time today.
>
>The TOC "...release notes" solution (as illustrated by the 17.0.4
>ones) seem fine, so until we come with a better idea I'll just go with
>it.
>
>-Emil
 
OK, I will update the remaining release notes with the proposed solution used 
in the 17.0.4;

One more question: Currently we have many new changes to the documentation in 
mesa master (like the new releases).
Should I rebase and port those to Sphinx too?
I'm asking because, if I rebase, the comments made on github will be lost.

Best Regards,
Jean Hertel  
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] - Rewrite mesa website in Sphinx

[Jean Hertel]

Hello,

Any update on this?
Is someone validating the github repository?

Thanks in advance.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] - Rewrite mesa website in Sphinx

[Jean Hertel]

Any throughts on this?

Emil, Did you have time to check the page I mentioned?

Best Regards,
Jean Hertel
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] - Rewrite mesa website in Sphinx

[Jean Hertel]

>On 2017-04-26 at 10:32, Emil Velikov  wrote:

>No worries - we can always change/polish the theme as needed.
>Just checking that there's nothing 'fundamentally broken' there.

It's already fixed. Check the repo and the live demo.


>Right - I was skimming through 4.1 where the spacing in the number
>lists is still funky.
>Either way I'm not saying that we should throw your work there. Just
>that those will need closer look (read will take more time) than their
>HTML brethren.

I will have a look there and see what can be improved.


>To visualise what I'm talking about observe the TOC as you open any of
>the [HTML] release notes.
>Replacing the second "Mesa ... release notes$date" with something
>like above would be great, but optional.

What a shame, I haven't seen this before.
I will update to a new format.
Before I make any change, I've manually changed just one file[1]
Can you check it and see if its OK now?
If not, please leave a comment and more suggestions :)

[1]: http://mesa2.jeanhertel.com.br/relnotes/17.0.4.html
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] - Rewrite mesa website in Sphinx

[Jean Hertel]

>On 2017-04-26 at 10:32, Emil Velikov  wrote:
>>>Thanks again for doing this Jean. A handful of, mostly trivial, questions.
>>>
>>> - Is there a website where one can check the output of specific
>>>Sphinx markdown.
>>
>> I have searched for such a thing too, but have not found :(
>>
>:-(

A quick note: Aurelio Silver sent me an email right now with an online
editor[1]. It seems very good for me.

[1]: https://livesphinx.herokuapp.com/
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] - Rewrite mesa website in Sphinx

[Jean Hertel]

On 2017-04-26 at 10:32, Emil Velikov  wrote:



No worries - we can always change/polish the theme as needed.
Just checking that there's nothing 'fundamentally broken' there.


It's already fixed. Check the repo and the live demo.



Right - I was skimming through 4.1 where the spacing in the number
lists is still funky.
Either way I'm not saying that we should throw your work there. Just
that those will need closer look (read will take more time) than their
HTML brethren.


I will have a look there and see what can be improved.



To visualise what I'm talking about observe the TOC as you open any of
the [HTML] release notes.
Replacing the second "Mesa ... release notes$date" with something
like above would be great, but optional.


What a shame, I haven't seen this before.
I will update to a new format.
Before I make any change, I've manually changed just one file[1]
Can you check it and see if its OK now?
If not, please leave a comment and more suggestions :)

[1]: http://mesa2.jeanhertel.com.br/relnotes/17.0.4.html

Note: This message will be sent twice to the list, because my outlook 
account is crazy and is sending messages very slowly.

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] - Rewrite mesa website in Sphinx

[Jean Hertel]

>On 2017-04-26 06:23, Eric Engestrom wrote:
> 
>
>Perfect, thanks!
>I left a couple comments on 0658cf3db95c77dbe590.
>
Ok, I will focus on fixing the issues pointed out.

>> 
>> Foot Note: Some changes are still necessary because some specification files 
>> (patents.txt, libGL.txt, features.txt, etc)
>> need to be exported directly to the output folder.
>
>I see you added a commit since your email (922e597521833875c9e5), which
>essentially exports all these files to the website.
>I'd argue most (if not all) of these files only make sense in the repo,
>not on the website, so I think that commit can be dropped.

I understand that those files are not essential, but would be nice
if we can leave them in the website, as Search Engines have already linked it.

>
>I suggest you fix any issue from now on with `--fixup` commits (I'm
>taking back my rebasing suggestion), and I'll squash those when merging.
>This way, comments left on github commits won't be lost by rebasing.
>
>I'll also squash your 3 "fix issue with sphinx-generator" with their
>respective file commits.

Ok, my next commits will use `--fixup`.
Thanks for the suggestion :)
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] - Rewrite mesa website in Sphinx

[Jean Hertel]

>On 2017-04-26 at 08:13, Emil Velikov  wrote:

>Thanks again for doing this Jean. A handful of, mostly trivial, questions.
>
> - Is there a website where one can check the output of specific
>Sphinx markdown.

I have searched for such a thing too, but have not found :(

> - Any ideas why the page contents are so narrow? It seems theme
>related, doesn't it.

Yes, it's theme related.
I have quickly readed the Kernel DRM docs, and it seems they have maded
a litle fix in the CSS for this. I will provide a fix soon too.

> - Personally I would not bother, yet, with the non-html documents.
>These are quite picky to format correctly, as you've spotted already.

Well, they are already formated now :)
I will fix the small issues pointed by Eric.

> - The Gallium and NIR documentation might be better suited in the toctree.

Ok, will fix that too.

> - Maybe apply something like the following to the release notes
>s|Mesa X Release Notes / $date|Overview\n\nRelease date: $date|
>

Do you mean in all the release notes?
Please remember that, the first title (the one with  at bottom) 
of the file is used by Sphinx when generating the links. 
So I have added two titles in every release note,
one for the link generation, and another for the original title.

>
>Thanks
>Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] - Rewrite mesa website in Sphinx

[Jean Hertel]

>On 2017-04-24 12:40, Eric Engestrom wrote:
>
>Sorry I haven't had time to look at this until now.
>
>I just had a look, and besides style that can be tweaked later, I think
>the main issue is that the homepage a visitor lands on when just typing
>'mesa3d.org' should be more than a simple duplicate of the ToC.
>
>The 'recent releases' list we currently have gives at least that
>information, and I would like to keep that until (if) we find something
>else/better.

OK, I've updated the demo site with this.
Please visit: http://mesa2.jeanhertel.com.br

>Another thing, can you please make a (rebasing) branch with a commit per
>file converted, where the old file is deleted and the new created?
>That way, it can be easily verified that the content was correctly
>converted (no information lost; typo fixes and the like are ok) and more
>importantly it makes it obvious at merge time that a file has been
>changed in its html form, and the corresponding change can be made on
>the rst file.

Ok, I've done one commit per file change, see it here: 
https://github.com/jlHertel/mesa/tree/sphinx-docs

Foot Note: Some changes are still necessary because some specification files 
(patents.txt, libGL.txt, features.txt, etc)
need to be exported directly to the output folder.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] - Rewrite mesa website in Sphinx

[Jean Hertel]

Hello Brian, thanks for the response.


About the docs title, it's already "The Mesa 3D Graphics Library".

If you have any doubts, please see an example of the generated website here: 
http://mesa2.jeanhertel.com.br/


About the font-size, that's defined directly by the theme.

It is possible to create your own CSS file to replace this, or write our own 
theme, but I think it's not worth the effort, especially since all websites 
that use this theme have this same font size.


Best Regards,

Jean Hertel


De: Brian Paul <bri...@vmware.com>
Enviado: quinta-feira, 20 de abril de 2017 16:10
Para: Emil Velikov; Jean Hertel; Eric Engestrom
Cc: Vedran Miletić; Jason Ekstrand; mesa-dev@lists.freedesktop.org
Assunto: Re: [Mesa-dev] [RFC] - Rewrite mesa website in Sphinx

On 04/19/2017 05:23 AM, Emil Velikov wrote:
> On 11 April 2017 at 13:10, Jean Hertel <jean.her...@hotmail.com> wrote:
>> Any more thoughts on this?
>>
>>
>> I would really appreciate feedback from more contributors.
>>
> Indeed.
>
> Brian, Eric, others - how do you feel with the Sphinx edition of the site?
> If the current theme feels a bit off there's others available [1].
> Then again, that can be changed/polished at any later stage.

I guess it looks OK to me.  I was looking more closely at Sphinx markup
and it seems pretty simple.

I think we'll want the mesa3d.org website to auto-update when someone
checks in changes to the Sphinx files.  Hopefully, the fd.o admins can
rig that up without too much trouble.

One note: I've always referred to the project as just "Mesa" or "The
Mesa 3-D Graphics Library".  I only used mesa3d.org for the website
because mesa.org was taken.  So I'd suggest replacing the string "Mesa
3D" with one of the others.

Also, could we use a slightly smaller font?  The text seems a bit larger
than necessary.

-Brian

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [RFC] - Rewrite mesa website in Sphinx

[Jean Hertel]

Any more thoughts on this?


I would really appreciate feedback from more contributors.


Best Regards.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [GSOC] DriConf Replacement

[Jean Hertel]

Nicolai,


Is there any place were I can find all the options with their respectives 
descriptions?

I have readed a little of information about DRI here[1], but i'm not very sure 
were I can find a doc about all those options.


About the language and the choice of full rewrite or incremental, I'm still 
thinking about it.

Currently I don't know GTK+ and Python.

C++ is a possible choice, as I already know a little about it.

I'm studying the options and will see what best fits my knowledge.



Best Regards


[1]: https://dri.freedesktop.org/wiki/ConfigurationForDevelopers/


De: Nicolai Hähnle <nhaeh...@gmail.com>
Enviado: quarta-feira, 5 de abril de 2017 05:26
Para: Jean Hertel; mesa-dev@lists.freedesktop.org
Assunto: Re: [Mesa-dev] [GSOC] DriConf Replacement

Hi Jean,

On 04.04.2017 01:52, Jean Hertel wrote:
> I would like to ask what are the proposed projects for Gsoc 2017.
> Specifically I want to know if someone proposed something to the Driconf
> replacement idea.

If you haven't already, try installing driconf and playing around with
it a bit. This should give you a reference point for how it works and
the kind of complaints people have about driconf.

Most of the user complaints are about the GUI being clunky and missing
features. For example, it doesn't properly deal with the PRIME setups
found in many laptops (internal GPU + external GPU). The way
application-specific settings work is pretty weird as well: Why is it a
separate pane of the window?

 From the Mesa developer point of view, there is one huge problem with
driconf which means we must advise users against using it right now: It
writes out a full ~/.drirc which overrides the system's /etc/drirc. So
when a user runs driconf once and then later updates Mesa, the
Mesa-provided /etc/drirc may have some changed options which are
effectively ignored.

Organizing a bit, here's a bunch of either smaller sub-projects to
evolve the current DriConf, or things to keep in mind for a full re-design:

1) Change DriConf to not write the full ~/.drirc every time, but only
the explicitly set options. DriConf should track options as "tri-state"
(On/Off/System-default).

2) Handle the multi-GPU case. This requires some GUI changes, obviously.
Under the hood, this requires directly enumerating the DRI device nodes
and loading the driver for each device.

2b) Currently, devices are identified by driver name, which is a bit
silly in A+A systems, where both the internal and the external GPU use
radeonsi. Evolve the drirc XML format in a way to identify the actual
device (by PCI ID makes the most sense, I think) instead of (possibly in
addition to?) the driver.

2c) Consider adding an option to configure PRIME to driconf.

[2b and 2c will also require changes in Mesa; also, you may want to get
rid of the implicit dependency on xdriinfo]

3) Re-design the GUI in general, keeping in mind that it should provide
a more natural way to define application-specific settings and
driver-specific settings, and a combination of those.

4) There's just a general bunch of cleanups for user-friendliness that
would be nice. For example, why is "Force GLSL extension default
behavior to 'warn'" under the "Debugging" category, when it really
should be under an "Application bug workaround" category? And options
like "Force a default GLSL version" should provide a drop-down box of
possible options rather than a generic integer slider. Note that many of
these cleanups actually require changes to Mesa as well.

This should give you a good idea of the kind of things that need to be
taken into account.

As for the replace/rewrite question: It's always tempting to say "I can
do better, let's rewrite everything", and if you're "just" in it for the
learning experience, then go for it! (This may be especially true if
there's a different GUI toolkit that you know by heart or you hate
Python; though I'd say that using a high-level language for GUI work
does have an advantage.)

However, think well about how much time you'll have to devote to this
task. I would estimate multiple full-time months of work for addressing
all of the above points properly. If you actually want to have a useful
contribution in the end, it may be better and more rewarding to work on
evolving the existing DriConf.

Cheers,
Nicolai


>
> Can anyone point me out?
>
> Thanks in advance.
>
> PS: I'm not elegible to the program, so please, don't reply saying that
> the subscription time is over, I already know it.
> --
> Enviado de meu dispositivo Android com K-9 mail. Desculpe-me pela
> brevidade.
>
>
> ___
> mesa-dev mailing list
> mesa-dev@lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/mesa-dev
>


--
Lerne, wie die Welt wirklich ist,
Aber vergiss niemals, wie sie sein sollte.
__

[Mesa-dev] [RFC] - Rewrite mesa website in Sphinx

[Jean Hertel]

Hello,


This is the second proposal for a rewrite of mesa website.


The last proposal have some problems (still available here: 
http://mesa.jeanhertel.com.br/):

  *   Use of big libraries like Twitter Bootstrap for the CSS;
  *   The design was focusing more on a blog-style instead of a documentation 
style;
  *   The rewrite was using Markdown, while there is already lots of 
documentation using reStructured Text;


This proposal tries to fix those issues.


Oficial repository: https://github.com/jlHertel/mesa-sphinx

Live demo: http://mesa2.jeanhertel.com.br/


As already pointed out, there was a conversion done some months ago by Nicholas 
Bishop. If you look carefully, you will note that my conversion is basically 
the same.


The point here is about other pieces of documentations that needs to be writen, 
or extracted from the source code.


I have readed some projects documentation (mainly in PHP) and the common case 
is to use tools like doxygen to generate an "API view" of classes, functions, 
etc.

And use the main website to write specific articles covering things not too 
obviously or to show some samples of usage.


To bring this approach to mesa, lets imagine an example with the GL Dispatch 
function.

In the main website (mesa3d.org) there is an article explaining exactly how the 
dispatcher works, why it was designed this way, and what advantages it can take 
on some operating systems and configurations.

In the API documentation site (that I imagine will be a sub-site under 
mesa3d.org) there will be the function/macro declarations for it.


Please, feel free to comment on this and suggest any other ideas.


Thanks in advance.


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [GSOC] DriConf Replacement

[Jean Hertel]

Hello,

I would like to ask what are the proposed projects for Gsoc 2017.
Specifically I want to know if someone proposed something to the Driconf 
replacement idea.

Can anyone point me out?

Thanks in advance.

PS: I'm not elegible to the program, so please, don't reply saying that the 
subscription time is over, I already know it.

Sorry if the message gets send twice, my e-mail client seems to be having a 
issue with the mailing list.

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [GSOC] DriConf Replacement

[Jean Hertel]

Hello,

I would like to ask what are the proposed projects for Gsoc 2017.
Specifically I want to know if someone proposed something to the Driconf 
replacement idea.

Can anyone point me out?

Thanks in advance.

PS: I'm not elegible to the program, so please, don't reply saying that the 
subscription time is over, I already know it.

___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [GSOC] DriConf Replacement

[Jean Hertel]

Hello,

I would like to ask what are the proposed projects for Gsoc 2017.
Specifically I want to know if someone proposed something to the Driconf 
replacement idea.

Can anyone point me out?

Thanks in advance.

PS: I'm not elegible to the program, so please, don't reply saying that the 
subscription time is over, I already know it.
--
Enviado de meu dispositivo Android com K-9 mail. Desculpe-me pela brevidade.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Request for Comments] - Port documentation to Markdown

[Jean Hertel]

Hello Emil,


I'm not sure if you have read the full conversation, but I changed my mind 
about this.

I have shifted focus to use Sphinx for website generation along with 
documentation.

As far as I can tell, there is already documentation about NIR and Gallium 
writen in ReStructured Text, which Sphinx can use.


The last two week I'm very busy at work, so I haven't made much progress on the 
website itself.

My hope is to release a new repository on github this weekend, with the initial 
website in a ReStructured Text format.


Best Regards,

Jean Hertel.

De: Emil Velikov <emil.l.veli...@gmail.com>
Enviado: quarta-feira, 29 de março de 2017 12:32
Para: Brian Paul
Cc: Jean Hertel; mesa-dev@lists.freedesktop.org
Assunto: Re: [Mesa-dev] [Request for Comments] - Port documentation to Markdown

Hi Jean,

On 8 March 2017 at 16:12, Brian Paul <bri...@vmware.com> wrote:

>> >One thing that I would prefer so not see if heavy things like
>> Bootstrap.
>> >We definitely don't need it, I think writing our own few lines of CSS
>> >(which can be inspired by anything you want) is better. We have more
>> >than enough people who know how to do it (myself included), it will
>> be
>> >cleaner (we won't need to include the whole forest to get our tree)
>> and
>> >much easier to fix when there's a bug.
>>
>>
>> I would tend to agree but I don't care too much about those details so
>> long as it's maintainable.  My primary concern is that while a lot of
>> random developers in the community are liable to have brushed into CSS a
>> time or two, most probably won't know bootstrap.
>
>
> Yeah, I can's stress that too much.  The site has to be easily maintainable
> by the developers.  I, for one, don't know much about websites beyond html
> and a little CSS.  If you create a new website infrastructure and then
> disappear after a few months we need to be able to take over.  Also, we
> can't funnel documentation updates through a handful of people that know a
> complex system.
>
Have you had some time to look into this ?

It would be great if we can get things rolling, even if not perfect.

Thanks
Emil
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Request for Comments] - Port documentation to Markdown

[Jean Hertel]

Jason,


First, thanks for pointing the other attempts of doing all that.

Reading those links and the responses in this thread my current opinion is:

  *   The developers want a place to put more documentation;
  *   Large CSS portions are not desired, so a very simple CSS is needed for 
better maintenance. (No Twitter Bootstrap allowed);
  *   Sphinx is preferred, as there is already some documentation written in 
it. (Gallium and NIR);

If you look carefully, right now the mesa website is splited in 3 main parts:

  *   New releases announces; (Those are mainly writed by Emil);
  *   Basic Helping and Debugging (Mailing lists, writing for Mesa, bug 
reporting, etc);
  *   Some Basic documentation on Mesa itself (Mesa Dispatch, Off-screen 
rendering, EnvVars, etc);


Given these points, is clear to me that a Sphinx approach is much more valuable.

I will try to understand it and write a new proposal for the website, along 
with the documentation.


Cheers,

Jean Hertel


De: Jason Ekstrand <ja...@jlekstrand.net>
Enviado: terça-feira, 7 de março de 2017 18:47
Para: Jean Hertel
Cc: Eric Engestrom; mesa-dev@lists.freedesktop.org
Assunto: Re: [Mesa-dev] [Request for Comments] - Port documentation to Markdown

Hey Jean,

First off, it's worth throwing out there that this is not the first proposal to 
do something like this, just the proposal with the prettiest demo :-)  A few 
references for you:

https://lists.freedesktop.org/archives/mesa-dev/2016-August/127178.html
https://lists.freedesktop.org/archives/mesa-dev/2015-June/085786.html
https://lists.freedesktop.org/archives/mesa-dev/2016-December/138196.html

In particular, the conversion of the entire mesa website to rst has already 
been done... twice.

One thing that I would personally like to see is for us to start building some 
Sphinx-based architecture-level documentation for mesa.  There is already some 
substantial gallium documentation written using RST and Sphinx and I have some 
pretty good chunks of NIR and ISL documentation floating around that I'd like 
to merge at some point but there's no good place to put it at the moment.  
Whether this sort of documentation ties into the website or is its own thing 
that developers just build from the git tree, I don't care too much.  However, 
given the way Sphinx is designed, just doing everything in Sphinx seems like a 
reasonable thing to do.
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

Re: [Mesa-dev] [Request for Comments] - Port documentation to Markdown

[Jean Hertel]

Eric, 

>>On Monday, 2017-03-06 18:36:32 +, Jean Hertel wrote:
>> Hello guys,
>> 
>> 
>> I want to propose a port of the current HTML documentation to a 
>> markdown-like syntax.
>> 
>
>I was thinking of doing essentially the same thing, just haven't had the
>time to do so yet. Please CC me (e...@engestrom.ch) on anything related
>to this project :)
>
>> 
>> Current problems
> > 
> > 
> > Right now I see some problems with the approach used.
> > 
> >   *   People maintaining the documentation must know basic HTML syntax;
> >   *   There is no easy way to add a new release page;
> >  *   You need to open the index file and make changes there;
> >  *   You need to make a new file that will say what has been changed;
> >  *   You need to remember to update the release notes pages;
> >   *   The current website has many HTML tags not being closed;
>>   *   The website don't fit well in mobile area. (The layout is not 
>> responsive);
>>   *   Making any change to the layout is very hard, because you need to 
>> rewrite many pages;
>>   *   The current website doesn't show all the possibilities of the library. 
>> The website has a 1990 layout, and I think having a new layout would benefit 
>> the project;
>
>Agreed on all counts :)
>
>> 
>> Proposal for Markdown
> > 
> > Rewriting the documentation in a markdown syntax can bring some benefits to 
> > the development, like:
> > 
> >   *   Anyone writing for freedesktop.org, StackOverflow and Github already 
> > knows the markdown syntax.
> >   *   Independence of HTML. The developer don't need to worry if the HTML 
> > output will be correct. The generator makes all the translation from 
> > markdown to HTML;
>
> Agreed, but more on this below.

> >   *   Easily change the layout of the site, simply changing the theme; (I 
> > don't think you change the layout much, but allowing it to be easy wont 
> > hurt)
>
> Having a proper (generated?) HTML structure and a clean CSS is all you
> need for this.
>
I agree.

> >   *   Creating a new release post can be maded easy, using some static site 
> > generator, for example, pelican;
>
> This can be done with any old tool. You could even have a simple
> release.template and copy it and modify it as you need to make a new
> release.

> > 
> > 
> > Right now I have maded a partial port from HTML to Markdown.
> > 
>> The code can be found here:  https://github.com/jlHertel/mesa-pelican
>
>I looked at your conversion on a couple random files, and it looks
>pretty good to me. (I have a couple nit-picks obviously :P, but the
>basic concept is fine.)

If you find any problem, you can report them directly via a github issue or 
send me an email. As soon as possible I will fix it.

>> 
>> I'm using the pelican static site generator with a layout ported from 
>> Wordpress using Twitter Bootstrap CSS.
>> 
>> A live preview can be found here: http://mesa.jeanhertel.com.br/
>> 
>> 
>> The static site generator tool and the theme used can be ignored if you 
>> want, the point here is to rewrite the documentation in a way that is easy 
>> to maintain and that >>don't need a good knowledge in HTML.
>
>I haven't look into Pelican (and won't have time to do so before the
>weekend), but I think it sounds like a reasonable kind of requirement to
>have. There are plenty of other markdown-to-html generators around, if
>someone prefers another one.

Agree, any generator is fine for me.

>One thing that I would prefer so not see if heavy things like Bootstrap.
>We definitely don't need it, I think writing our own few lines of CSS
>(which can be inspired by anything you want) is better. We have more
>than enough people who know how to do it (myself included), it will be
>cleaner (we won't need to include the whole forest to get our tree) and
>much easier to fix when there's a bug.

As I already answered Emil, I have put it there because of mylack of knowledge 
on doing good CSS.
Of course you're welcome to help me write a more clean CSS. Any help and 
suggestion is very apreciated.

>One core thing that might need to be changed is Markdown itself. It is
>great for prose, but it breaks down quite quickly when you start to
>write code in it. For this reason, people are moving to RST instead for
>code documentation.
>
>The question becomes: how much code do we expect to put on the website,
>and how complex will it be?
>
>I had in mind that we could start adding small code examples to help new
>learners to understand how the apis are used. No tutorial-style

Re: [Mesa-dev] [Request for Comments] - Port documentation to Markdown

[Jean Hertel]

Hello Emil,

> Some people have suggested Sphinx - are you familiar with it, do you know 
> similar tools for it ?
I really don't know Sphinx.
From what I have readed (In wikipedia) it basically converts reStructured Text 
to HTML.
Of course Pelican can do this too.
But I think markdown is more widely adopted.


> How did you convert the existing pages, are there any plans on doing the rest 
> ?
The conversion is done by hand. This is why I know there are some HTML tags not 
being closed.
The plan for conversion is when I have free time, my expectation is to have the 
remaining NEWS converted until 12/03.


> Do we need the clunky Bootstrap/jQuert JS ?
I have used both jQuery and Bootstrap because of the already done testing/large 
adoption. The tools are very big, unfortunately :(
Of course any layout is possible, so the answer for your question is: We can 
make whatever is wanted, but then, we need to test very carefully on a wide 
range of displays and browsers do ensure the good is good and don't break. 
Unfortunately my knowledge in the area of responsive design is somewhat limited.

What comes to my mind right now is the use of a CDN 
(https://en.wikipedia.org/wiki/Content_delivery_network) to ease the server 
load. For this, we need only someone to provide us one. As an open source 
project, I don't really see this as a problem. Maybe asking Google and using 
their CDNs.


Best Regards

Jean Hertel

Em 06-03-2017 18:35, Emil Velikov escreveu:

Hi Jean,

On 6 March 2017 at 18:36, Jean Hertel 
<jean.her...@hotmail.com><mailto:jean.her...@hotmail.com> wrote:


Hello guys,


I want to propose a port of the current HTML documentation to a
markdown-like syntax.


Current problems


Right now I see some problems with the approach used.

People maintaining the documentation must know basic HTML syntax;
There is no easy way to add a new release page;

You need to open the index file and make changes there;
You need to make a new file that will say what has been changed;
You need to remember to update the release notes pages;

The current website has many HTML tags not being closed;
The website don't fit well in mobile area. (The layout is not responsive);
Making any change to the layout is very hard, because you need to rewrite
many pages;
The current website doesn't show all the possibilities of the library. The
website has a 1990 layout, and I think having a new layout would benefit the
project;

Proposal for Markdown

Rewriting the documentation in a markdown syntax can bring some benefits to
the development, like:

Anyone writing for freedesktop.org, StackOverflow and Github already knows
the markdown syntax.
Independence of HTML. The developer don't need to worry if the HTML output
will be correct. The generator makes all the translation from markdown to
HTML;
Easily change the layout of the site, simply changing the theme; (I don't
think you change the layout much, but allowing it to be easy wont hurt)
Creating a new release post can be maded easy, using some static site
generator, for example, pelican;


Right now I have maded a partial port from HTML to Markdown.

The code can be found here: https://github.com/jlHertel/mesa-pelican

I'm using the pelican static site generator with a layout ported from
Wordpress using Twitter Bootstrap CSS.

A live preview can be found here: http://mesa.jeanhertel.com.br/


The static site generator tool and the theme used can be ignored if you
want, the point here is to rewrite the documentation in a way that is easy
to maintain and that don't need a good knowledge in HTML.


Please leave your comments on the proposal.




Not sure if I agree with some of your points, then again i don't need
any - I'm already sold ;-)
Thanks you very much !

A couple of questions:
 - Some people have suggested Sphinx - are you familiar with it, do
you know similar tools for it ?
 - How did you convert the existing pages, are there any plans on
doing the rest ?
 - Do we need the clunky Bootstrap/jQuert JS ?

-Emil


___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev

[Mesa-dev] [Request for Comments] - Port documentation to Markdown

[Jean Hertel]

Hello guys,


I want to propose a port of the current HTML documentation to a markdown-like 
syntax.


Current problems


Right now I see some problems with the approach used.

  *   People maintaining the documentation must know basic HTML syntax;
  *   There is no easy way to add a new release page;
 *   You need to open the index file and make changes there;
 *   You need to make a new file that will say what has been changed;
 *   You need to remember to update the release notes pages;
  *   The current website has many HTML tags not being closed;
  *   The website don't fit well in mobile area. (The layout is not responsive);
  *   Making any change to the layout is very hard, because you need to rewrite 
many pages;
  *   The current website doesn't show all the possibilities of the library. 
The website has a 1990 layout, and I think having a new layout would benefit 
the project;

Proposal for Markdown

Rewriting the documentation in a markdown syntax can bring some benefits to the 
development, like:

  *   Anyone writing for freedesktop.org, StackOverflow and Github already 
knows the markdown syntax.
  *   Independence of HTML. The developer don't need to worry if the HTML 
output will be correct. The generator makes all the translation from markdown 
to HTML;
  *   Easily change the layout of the site, simply changing the theme; (I don't 
think you change the layout much, but allowing it to be easy wont hurt)
  *   Creating a new release post can be maded easy, using some static site 
generator, for example, pelican;


Right now I have maded a partial port from HTML to Markdown.

The code can be found here: https://github.com/jlHertel/mesa-pelican

I'm using the pelican static site generator with a layout ported from Wordpress 
using Twitter Bootstrap CSS.

A live preview can be found here: http://mesa.jeanhertel.com.br/


The static site generator tool and the theme used can be ignored if you want, 
the point here is to rewrite the documentation in a way that is easy to 
maintain and that don't need a good knowledge in HTML.


Please leave your comments on the proposal.


Best Regards

Jean Hertel


--

Some terms used are web-focused, so I will leave some links if anyone don't 
know what I mean:

Twitter Bootstrap Css: http://getbootstrap.com/

Responsive layout: https://en.wikipedia.org/wiki/Responsive_web_design

Pelican static site generator: https://blog.getpelican.com/

Markdown: https://en.wikipedia.org/wiki/Markdown
___
mesa-dev mailing list
mesa-dev@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/mesa-dev