rockbox/manual/appendix/appendix.tex
Moshe Piekarski 0aa702836b Manual: remove most HWCODEC artifacts
This causes 3 changes in layout. 2 I can't track down and 1 is better this way.

Change-Id: If4ad5e1d7431b4c2cbaaf9767d78139ef4e2dc44
2020-11-18 14:35:09 +00:00

113 lines
4.7 KiB
TeX

% $Id$ %
\appendix
\input{appendix/file_formats.tex}
\input{appendix/album_art_info.tex}
\input{appendix/wps_tags.tex}
\input{appendix/config_file_options.tex}
\input{appendix/menu_structure.tex}
\chapter{User feedback}\label{sec:feedback}
\section{Bug reports}
If you experience inappropriate performance from any supported feature,
please file a bug report on our web page. Do not report missing
features as bugs, instead file them as feature ideas (see below).
For open bug reports refer to
\url{http://www.rockbox.org/tracker/index.php?type=2}
\subsection{Rules for submitting new bug reports}
\begin{enumerate}
\item Check that the bug has not already been reported
\item Always include the following information in your bug report:
\begin{itemize}
\item Which exact \dap{} you have.
\item Which exact Rockbox version you are using
(Menu $\rightarrow$ System $\rightarrow$ Rockbox Info $\rightarrow$ Version)
\item A step{}-by{}-step description of what you did and what happened
\item Whether the problem is repeatable or a one{}-time occurrence
\item All relevant data regarding the problem, such as playlists, MP3
files etc. (IMPORTANT!)
\end{itemize}
\end{enumerate}
\section{Feature ideas}
To suggest an idea for a feature or to read those made by others, see
\url{http://forums.rockbox.org/index.php?board=49.0}. Please keep in
mind that this forum is for the discussion of feature ideas -- they are not
requests and there is no guarantee they will be acted upon.
\subsection{Rules for submitting a new feature idea}
\begin{enumerate}
\item Check that the feature has not already been suggested.
Duplicates are really boring!
\item Check that the feature has not already been implemented.
Download the latest current/daily build and/or search the mail list archive.
\item Check that the feature is possible to implement (see \reference{ref:NODO}).
\end{enumerate}
\subsection{\label{ref:NODO}Features we will not implement}
This is a list of Feature Requests we get repeatedly that we simply
cannot do. View it as the opposite of a TODO!
\begin{itemize}
\nopt{iriverh300,iaudiox5}{
\item Interfacing with other USB devices (like cameras) or 2 player games over USB.\\
The USB system demands that there is a master that talks to a slave. The
\dap{} can only serve as a slave, as most other USB devices such as
cameras can. Thus, without a master no communication between the slaves
can take place. If that is not enough, we have no way of actually
controlling the communication performed over USB since the USB circuit
in the \dap{} is strictly made for disk{}-access and does not allow us
to play with it the way we'd need for any good communication to work.
}
\item Support other file systems than FAT32 (like NTFS or ext2 etc.).\\
No. (Except perhaps for ExFAT)
Most \dap{}s can only start off FAT32 partitions, so adding support
for more file systems will just take away valuable ram for
unnecessary features. You can partition your \dap{} fine, just make sure
the first one is FAT32 and then make the other ones whatever file system
you want. Just do not expect Rockbox to understand them.
\item Add scandisk{}-like features.\\
It would be a very slow operation that would drain the batteries and
take a lot of useful ram for something that is much better and faster
done when connected to a host computer.
\item Alphabetical list skipping.\\
Skipping around the lists by jumping letters (i.e skip all C's and go
straight to the first D). This isn't feasible with the current list
implementation, if you really want this you can get similar effects using
the database (see \reference{ref:database}).
\item Add support for non standard tag formats.\\
APE tags in MP3 files has been rejected a few times already. Its not something we want.
\item Implementing the ability to playback DRM files.\\
Firstly, this would be extremely difficult to implement legally -- Rockbox
is not legal entity as such, and therefore is unable to enter into license
agreements with providers of DRM technology.
Secondly, Rockbox is open source, which would mean that any DRM technology we
incorporated into our codebase would suddenly become visible to the whole world,
completely defeating its purpose. Remember, DRM achieves part of its security
through obscurity, and publishing the keys necessary to decrypt DRM'd
media would essentially render it useless.
\end{itemize}
\chapter{Credits}
People that have contributed to the project, one way or another. Friends!
%
\begin{multicols}{2}
\noindent\caps{\small{\input{CREDITS.tex}}}
\end{multicols}
\chapter{Licenses}
\section{GNU Free Documentation License}
\input{appendix/fdl.tex}
\newpage
\section{The GNU General Public License}
\input{appendix/gpl-2.0.tex}